Re: [PATCHES] Postgresql.conf Documentation change - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Postgresql.conf Documentation change
Date
Msg-id 12555.1092950889@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Postgresql.conf Documentation change  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [PATCHES] Postgresql.conf Documentation change  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> By removing comments from postgresql.conf, I am afraid we are making all
> environment value useless.

Good point.

> I suppose the easiest fix would be to re-command the postgresql.conf
> values that can be over-ridden with environment variables, or make
> environment variables more significant than postgresql.conf values, and,
> being in beta, which should we do now and which should we do for 8.1?

The current ordering of the PGC_S_xxx priorities was certainly chosen
with the idea that postgresql.conf would only set values that the DBA
had explicitly selected.  We'd need to rethink that if we uncomment
everything by default.

Making the env variables more significant than postgresql.conf seems
like a bad idea, because then there is no way to override 'em without a
postmaster restart.  (On the other hand, we consider postmaster command
line switches more significant than postgresql.conf, which is also wrong
if you consider that argument significant.)  This doesn't matter so much
for PGPORT but it's certainly relevant for PGDATESTYLE and
PGCLIENTENCODING.  Perhaps we could get away with it if we removed the
environment vars that are related to settings that can change after
postmaster start ... they seem like legacy items anyway.

Another possibility is to reconsider the original objection, which was
"re-commenting-out a postgresql.conf entry doesn't cause the value to
revert to default".  I have kinda brushed that off before, but if
postgresql.conf is only above PGC_S_DEFAULT then it wouldn't be too hard
to make it happen.

Right at the moment my feeling is that there are issues here that are
considerably more subtle than we realized, and rather than risk creating
unforeseen problems, we ought to bounce the whole issue back to the TODO
list for 8.1.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Postgresql.conf Documentation change
Next
From: "Simon Riggs"
Date:
Subject: Re: repeatable system index corruption on 7.4.2