Postgres Pro
Downloads
Home   >   mailing lists

Thread: dot-conf checking

dot-conf checking

From
Josh Berkus
Date:
Folks,

Here's some things I'd like to check on before submitting a bug patch on the 
.conf stuff:

1) TimeZone and DateStyle are mixed case in SHOW ALL.  Is there a reason for 
this?   Appears to be the same in 7.4.

2) for unix_socket_permissions  the value in the .conf file is octal (0777), 
while SHOW is decimal (511).

3) The .conf file says that rendezvous_name "defaults to host name".  However, 
it appears to default to UNSET.  Is the .conf file wrong, or initdb?

4) Am I correct that these are the only values set at initdb/compile time?wal_sync_methodtimezoneclient_encodinglc_*

Thanks for feedback!

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Re: dot-conf checking

From
Tom Lane
Date:
Josh Berkus <josh@agliodbs.com> writes:
> 1) TimeZone and DateStyle are mixed case in SHOW ALL.  Is there a reason for 
> this?   Appears to be the same in 7.4.

That's been the traditional spelling of those variable names since
before I got here.  Do we need to change it?

> 2) for unix_socket_permissions  the value in the .conf file is octal (0777), 
> while SHOW is decimal (511).

Not a whole lot we can do about that, unless you want to invent a new
category of "integer variables we display in octal".  Doesn't really
seem worth it.

> 3) The .conf file says that rendezvous_name "defaults to host name".
> However, it appears to default to UNSET.  Is the .conf file wrong, or
> initdb?

Neither.  It defaults to an empty string, which is interpreted as
"unset" by SHOW, but the code in postmaster.c takes that to mean "use
the machine name".  This is documented someplace but maybe not enough
places...
        regards, tom lane

Re: dot-conf checking

From
Josh Berkus
Date:
Tom,

> > 1) TimeZone and DateStyle are mixed case in SHOW ALL.  Is there a reason
> > for this?   Appears to be the same in 7.4.
>
> That's been the traditional spelling of those variable names since
> before I got here.  Do we need to change it?

Well, if we've had it for 5 years, then I guess another version won't hurt me; 
especially since this is the first time I really noticed it.  I'll put in for 
a change in 8.1.

> Not a whole lot we can do about that, unless you want to invent a new
> category of "integer variables we display in octal".  Doesn't really
> seem worth it.

I suppose so.   I'll want to document the discrepancy though.

> Neither.  It defaults to an empty string, which is interpreted as
> "unset" by SHOW, but the code in postmaster.c takes that to mean "use
> the machine name".  This is documented someplace but maybe not enough
> places...

I'll check the SGML tommorrow.  Thanks for replies.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Re: dot-conf checking

From
Tom Lane
Date:
Josh Berkus <josh@agliodbs.com> writes:
>> Not a whole lot we can do about that, unless you want to invent a new
>> category of "integer variables we display in octal".  Doesn't really
>> seem worth it.

> I suppose so.   I'll want to document the discrepancy though.

[ dept. of second thoughts ]  One idea would be to redefine the variable
as a string instead of an int, and store "0777" literally.  We'd have to
do the sscanf on use rather than on entry.  But seeing that the value is
only used once in the life of a postmaster, there could hardly be any
big objection about efficiency ...
        regards, tom lane