Обсуждение: Bug #652: NAMEDATALEN limitations

Erik Erkelens (Erik_Erkelens@yahoo.com) reports a bug with a severity of 3
The lower the number the more severe it is.

Short Description
NAMEDATALEN limitations

Long Description
If NAMEDATALEN is given values of 45,61 initdb -d  will fail with the error "relation pg_proc does not exist'.

I'd appreciate a comment in e.g. postgress_ext.h telling me e.g. that it should be a power of two, even or something
likethat. 

Sample Code


No file was uploaded with this report

pgsql-bugs@postgresql.org writes:
> If NAMEDATALEN is given values of 45,61 initdb -d  will fail with the error "relation pg_proc does not exist'.

Did you try to track down why?

Although it's inefficient to declare NAMEDATALEN as not a multiple of 4
(because of alignment considerations --- the space will just be wasted
as pad bytes, so you might as well use it), I don't offhand know why it
wouldn't work.  I don't *think* there is any assumption that it's a
power of 2 ... but the well-tested cases are all powers of 2, so ...

> I'd appreciate a comment in e.g. postgress_ext.h telling me e.g. that it should be a power of two, even or something
likethat. 

To do that, we'd need to know what the constraint actually is.  Do you
care enough to do the research to find out?

From my perspective it'd be even better to remove whatever the
constraint is, if it turns out to be a localized fix.  But not knowing
what's causing the failure, it's hard to guess.

            regards, tom lane

I said:
> Although it's inefficient to declare NAMEDATALEN as not a multiple of 4
> (because of alignment considerations --- the space will just be wasted
> as pad bytes, so you might as well use it), I don't offhand know why it
> wouldn't work.

One possible theory is that if NAMEDATALEN isn't a multiple of
sizeof(int), the compiler's idea of sizeof(NameData) will probably be
NAMEDATALEN rounded up to the next multiple of sizeof(int).  However,
I still don't see exactly how that breaks anything, with the possible
exception of pg_language tuple layout --- but pg_language layout
problems wouldn't give rise to a failure during bootstrap AFAICS.
So I still don't know what the constraint mechanism really is.

BTW, I'm assuming here that alignof(int) is 4 on your platform; is it?

            regards, tom lane

I said:
> One possible theory is that if NAMEDATALEN isn't a multiple of
> sizeof(int), the compiler's idea of sizeof(NameData) will probably be
> NAMEDATALEN rounded up to the next multiple of sizeof(int).

For the record, this does indeed seem to be the root cause for Erik's
complaint.  relcache.c declares the key size for its relation name
cache index as sizeof(NameData) --- so if that's larger than NAMEDATALEN
the hashtable code will end up trying to compare pad bytes that
probably haven't been zeroed out.

It looks to me like it would not really be practical to expect the
system to work when sizeof(NameData) is different from NAMEDATALEN;
we could maybe eliminate the existing discrepancies but more would
surely creep in.  So I've added comments to document that NAMEDATALEN
must be a multiple of sizeof(int).

BTW, I suspect that Names used as hashtable keys may explain the
residual speed differences that people have been reporting for large
values of NAMEDATALEN.  The dynahash.c code assumes fixed-length keys
and will compare all bytes out to the specified length, no matter what
--- so the extra cycles may all be spent in key comparisons for
dynahash tables.  Perhaps this could be fixed.

            regards, tom lane