Обсуждение: Re: [PATCHES] Postgresql.conf Documentation change
I had a problem with this patch. By removing the comment from 'port',
the postgresql.conf 'port' value is used in the regression tests rather
than the environment value. I see in guc.c
env = getenv("PGPORT"); if (env != NULL) SetConfigOption("port", env, PGC_POSTMASTER, PGC_S_ENV_VAR);
but, look at this:typedef enum{ PGC_S_DEFAULT, /* wired-in default */ PGC_S_ENV_VAR, /*
postmasterenvironment variable */ PGC_S_FILE, /* postgresql.conf */ PGC_S_ARGV,
/*postmaster command line */ PGC_S_UNPRIVILEGED, /* dividing line for USERLIMIT */ PGC_S_DATABASE,
/* per-database setting */ PGC_S_USER, /* per-user setting */ PGC_S_CLIENT, /*
fromclient connection request */ PGC_S_OVERRIDE, /* special case to forcibly set default */
PGC_S_INTERACTIVE, /* dividing line for error reporting */ PGC_S_TEST, /* test per-database
orper-user setting */ PGC_S_SESSION /* SET command */} GucSource;
which says that the config file value overrides the environment value.
By removing comments from postgresql.conf, I am afraid we are making all
environment value useless.
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?
Comments?
---------------------------------------------------------------------------
Josh Berkus wrote:
> Tom,
>
> Attached is that patch I talked to you about on hackers. It changes the
> description at the top and uncomments most (but not all) of the lines in an
> effort to make it clear that commenting is not a way to restore the defaults.
>
> I've tested this on my machine and we end up with the exact same defaults with
> this patch as without, so no changes to initdb should be required.
>
> --
> -Josh Berkus
>
> ______AGLIO DATABASE SOLUTIONS___________________________
> Josh Berkus
> Enterprise vertical business josh@agliodbs.com
> and data analysis solutions (415) 752-2500
> and database optimization fax 752-2387
> utilizing Open Source technology San Francisco
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
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
Tom, > 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. Agreed. I will submit a new patch that simply adds a cautionary note to postgresql.conf explaining the re-commenting issue. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > Tom, > > > 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. > > Agreed. I will submit a new patch that simply adds a cautionary note to > postgresql.conf explaining the re-commenting issue. Yes, agreed. Who knows what other issues we might hit if we went ahead, and the confusion we would cause for beta testers who already tested beta1. Update TODO item: * Un-comment all variables in postgresql.conf By not showing commented-out variables, we discourage people from thinking that re-commenting a variable returns it to itsdefault. Another option is to allow commented values to return to their default values. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073