Thread: Addition to: Trouble with initdb when the #define NAMEDATALEN = 51

Addition to: Trouble with initdb when the #define NAMEDATALEN = 51

From
"G. Anthony Reina"
Date:
Sorry, I forgot to include that I'm compiling this on RedHat 6.2,
Pentium III with Postgres 7.1.1.

-Tony



> I'm not sure if this is still needed in postgres to define the length of
> a variable/table name.
>
> In postgres_ext.h, I changed:
>
> #define NAMEDATALEN 32
> to
> #define NAMEDATALEN 51
>
> Everything compiled and installed. However, the initdb started up but
> then just said that it failed.
>
> I did a gmake clean and changed the 51 back to 32 and everything went
> through correctly (make, install, and initdb). Can anyone else verify if
> this is correct or even makes sense?
>
> Thanks.
> -Tony
>
>



"G. Anthony Reina" <reina@nsi.edu> writes:
>> In postgres_ext.h, I changed:
>> 
>> #define NAMEDATALEN 32
>> to
>> #define NAMEDATALEN 51
>> 
>> Everything compiled and installed. However, the initdb started up but
>> then just said that it failed.

I have not tried that in awhile, but the last time I did, it worked
fine.  Are you sure you did a *complete* rebuild?  I'd suggest make
distclean at the top level, configure, make all, install, initdb.

BTW, 51 is a gratuitously wasteful setting --- given alignment
considerations, any value that's not a multiple of 4 is pointless.
(It should work ... but it's pointless.)
        regards, tom lane


Re: Addition to: Trouble with initdb when the #define NAMEDATALEN = 51

From
Lincoln Yeoh
Date:
At 12:35 AM 5/12/01 -0400, Tom Lane wrote:
>BTW, 51 is a gratuitously wasteful setting --- given alignment
>considerations, any value that's not a multiple of 4 is pointless.
>(It should work ... but it's pointless.)

Would n^2-1 or n*8 -1 be better than n^2 or n*8? 

For postgresql it's in the source somewhere, but assuming we can't look,
which would be a better bet? 

Cheerio,
Link.



Re: Re: Addition to: Trouble with initdb when the #define NAMEDATALEN = 51

From
Peter Eisentraut
Date:
Lincoln Yeoh writes:

> At 12:35 AM 5/12/01 -0400, Tom Lane wrote:
> >BTW, 51 is a gratuitously wasteful setting --- given alignment
> >considerations, any value that's not a multiple of 4 is pointless.
> >(It should work ... but it's pointless.)
>
> Would n^2-1 or n*8 -1 be better than n^2 or n*8?

The important issue here is the storage layout of the system catalog
tuples.  If you take a look you will see that in most tables the field
after a name field is either an oid or an int4, both of which generally
require 4-byte alignment.  Since names are also 4-byte aligned you will
waste up to 3 bytes in padding if you don't choose NAMEDATALEN a multple
of 4.

Note that the system will actually only allow NAMEDATALEN-1 characters in
a name, maybe you were referring to that.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> At 12:35 AM 5/12/01 -0400, Tom Lane wrote:
>> BTW, 51 is a gratuitously wasteful setting --- given alignment
>> considerations, any value that's not a multiple of 4 is pointless.
>> (It should work ... but it's pointless.)

> Would n^2-1 or n*8 -1 be better than n^2 or n*8? 

No.  There is a pad byte involved, but it's included in NAMEDATALEN
(ie, if you set it to 64, you really get names up to 63 characters).
You want NAMEDATALEN itself to be a round number, since if it's not
the following byte(s) will just be wasted for alignment padding anyway.
        regards, tom lane


Re: Addition to: Trouble with initdb when the #define NAMEDATALEN = 51

From
"G. Anthony Reina"
Date:
Tom Lane wrote:

> "G. Anthony Reina" <reina@nsi.edu> writes:
> >> In postgres_ext.h, I changed:
> >>
> >> #define NAMEDATALEN 32
> >> to
> >> #define NAMEDATALEN 51
> >>
> >> Everything compiled and installed. However, the initdb started up but
> >> then just said that it failed.
>
> I have not tried that in awhile, but the last time I did, it worked
> fine.  Are you sure you did a *complete* rebuild?  I'd suggest make
> distclean at the top level, configure, make all, install, initdb.
>

I did a 'gmake clean'. I'll try again today. Perhaps I'll find something
that I was overlooking on Friday.

-Tony