Postgresql.conf Documentation change
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
Attachments:
postgresql.conf.patchtext/x-diff; charset=us-ascii; name=postgresql.conf.patchDownload+246-241
What would people like done with this patch? A sample section is:
! datestyle = 'iso, mdy'
! #timezone = {enviroment} # actually, defaults to TZ environment setting
! # set at initdb time
! australian_timezones = false
! extra_float_digits = 0 # min -15, max 2
! #client_encoding = {db encoding} # actually, defaults to database encoding
! # common: UNICODE, SQL_ASCII
He has kept comments on the items where we can't determine a default.
One issue is that the postgresql.conf file only gets installed as part
of initdb so a shutdown/install/restart will replace the sample file,
but the server file will retain comments until an initdb. This means
some beta people might go into 8.0.0 final with comments, and some will
not.
---------------------------------------------------------------------------
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, Pennsylvania 19073
Bruce,
One issue is that the postgresql.conf file only gets installed as part
of initdb so a shutdown/install/restart will replace the sample file,
but the server file will retain comments until an initdb. This means
some beta people might go into 8.0.0 final with comments, and some will
not.
I think there's a couple other patches that have the same effect (that is,
initdb is required to take care of them). I think people using the beta
should expect to re-build several times, anyway -- if they're not, they
shouldn't use beta software.
Also, this is basically a "documentation" bug, intended to make
postgresql.conf easier to understand, so even if some beta tester doesn't
load it, postgresql.conf still works ..
--
Josh Berkus
Aglio Database Solutions
San Francisco
On Mon, 16 Aug 2004, Josh Berkus wrote:
Bruce,
One issue is that the postgresql.conf file only gets installed as part
of initdb so a shutdown/install/restart will replace the sample file,
but the server file will retain comments until an initdb. This means
some beta people might go into 8.0.0 final with comments, and some will
not.I think there's a couple other patches that have the same effect (that is,
initdb is required to take care of them). I think people using the beta
should expect to re-build several times, anyway -- if they're not, they
shouldn't use beta software.
Actually, I agree with this, but from a different angle ... if testing
beta, part of that testing is that an initdb does what is expected and
doesn't generate any errors/problems ... when we go into RC mode, *then*
things should be safe from an initdb, but beta shouldn't have that
requirement ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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, /* postmaster environment 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, /* from client 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 or per-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, Pennsylvania 19073
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 its default.
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, Pennsylvania 19073
Patch withdrawn to be revisited in 8.1.
---------------------------------------------------------------------------
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, Pennsylvania 19073