-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruce Momjian wrote:

| Gaetano Mendola wrote:
|
|>Bruce Momjian wrote:
|>
|> > I understand your points below.  However, the group has weighed in the
|> > direction of clearly showing non-default values and not duplicating
|> > documentation.  We can change that, but you will need more folks
|> > agreeing with your direction.
|>
|>I don't remember the behaviour but tell me what happen if
|>I comment out a value changing the value. Kill UP the postmater.
|>Recommenting that value and now re killing the postmaster.
|>
|>I believe that postmaster will not run with the default value.
|>Who will look the configuration file will not understand the right
|>reality.
|
|
| If you comment a variable in postgresql.conf, it will use the
| default value.

That's not true at least with the version 7.4.2.

Try yourself, I did the experiment changing the cpu_tuple_cost and
commenting out the cpu_tuple_cost, after sending the SIGHUP to
postmaster the value remain: 0.005 that is not the default value at
all.



Regards
Gaetano Mendola








-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAyWbI7UpzwH2SGd4RAre5AJ4sakTxqvcjbq8Cz6Qoj2bnDO5/7gCfTWdp
nyWvDNTeQNEfwYJWHHL+0W0=
=JFgw
-----END PGP SIGNATURE-----


Fri, 11 Jun 2004 10:01:13 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Improving postgresql.conf
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bruce Momjian wrote:
> 
> | Gaetano Mendola wrote:
> |
> |>Bruce Momjian wrote:
> |>
> |> > I understand your points below.  However, the group has weighed in the
> |> > direction of clearly showing non-default values and not duplicating
> |> > documentation.  We can change that, but you will need more folks
> |> > agreeing with your direction.
> |>
> |>I don't remember the behaviour but tell me what happen if
> |>I comment out a value changing the value. Kill UP the postmater.
> |>Recommenting that value and now re killing the postmaster.
> |>
> |>I believe that postmaster will not run with the default value.
> |>Who will look the configuration file will not understand the right
> |>reality.
> |
> |
> | If you comment a variable in postgresql.conf, it will use the
> | default value.
> 
> That's not true at least with the version 7.4.2.
> 
> Try yourself, I did the experiment changing the cpu_tuple_cost and
> commenting out the cpu_tuple_cost, after sending the SIGHUP to
> postmaster the value remain: 0.005 that is not the default value at
> all.

Oh, sorry, you are right.  Not sure if this is a bug or not.

-- 
  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

Fri, 11 Jun 2004 13:02:52 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Improving postgresql.conf
On Fri, 2004-06-11 at 11:02, Bruce Momjian wrote:
> Gaetano Mendola wrote:
> [ PGP not available, raw data follows ]
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Bruce Momjian wrote:
> > 
> > | Gaetano Mendola wrote:
> > |
> > |>Bruce Momjian wrote:
> > |>
> > |> > I understand your points below.  However, the group has weighed in the
> > |> > direction of clearly showing non-default values and not duplicating
> > |> > documentation.  We can change that, but you will need more folks
> > |> > agreeing with your direction.
> > |>
> > |>I don't remember the behaviour but tell me what happen if
> > |>I comment out a value changing the value. Kill UP the postmater.
> > |>Recommenting that value and now re killing the postmaster.
> > |>
> > |>I believe that postmaster will not run with the default value.
> > |>Who will look the configuration file will not understand the right
> > |>reality.
> > |
> > |
> > | If you comment a variable in postgresql.conf, it will use the
> > | default value.
> > 
> > That's not true at least with the version 7.4.2.
> > 
> > Try yourself, I did the experiment changing the cpu_tuple_cost and
> > commenting out the cpu_tuple_cost, after sending the SIGHUP to
> > postmaster the value remain: 0.005 that is not the default value at
> > all.
> 
> Oh, sorry, you are right.  Not sure if this is a bug or not.

This point has come up before, and I think it's intended behavior. 
Stopping and restarting the database will, of course, make it load the
defaults.


Fri, 11 Jun 2004 11:15:50 -0600
"Scott Marlowe" <smarlowe@qwest.net>
Re: Improving postgresql.conf
Scott Marlowe wrote:

> On Fri, 2004-06-11 at 11:02, Bruce Momjian wrote:
> 
>>Gaetano Mendola wrote:
>>[ PGP not available, raw data follows ]
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>Bruce Momjian wrote:
>>>
>>>| Gaetano Mendola wrote:
>>>|
>>>|>Bruce Momjian wrote:
>>>|>
>>>|> > I understand your points below.  However, the group has weighed in the
>>>|> > direction of clearly showing non-default values and not duplicating
>>>|> > documentation.  We can change that, but you will need more folks
>>>|> > agreeing with your direction.
>>>|>
>>>|>I don't remember the behaviour but tell me what happen if
>>>|>I comment out a value changing the value. Kill UP the postmater.
>>>|>Recommenting that value and now re killing the postmaster.
>>>|>
>>>|>I believe that postmaster will not run with the default value.
>>>|>Who will look the configuration file will not understand the right
>>>|>reality.
>>>|
>>>|
>>>| If you comment a variable in postgresql.conf, it will use the
>>>| default value.
>>>
>>>That's not true at least with the version 7.4.2.
>>>
>>>Try yourself, I did the experiment changing the cpu_tuple_cost and
>>>commenting out the cpu_tuple_cost, after sending the SIGHUP to
>>>postmaster the value remain: 0.005 that is not the default value at
>>>all.
>>
>>Oh, sorry, you are right.  Not sure if this is a bug or not.
> 
> 
> This point has come up before, and I think it's intended behavior. 
> Stopping and restarting the database will, of course, make it load the
> defaults.

Yes and this doesn't help to understand how the postmaster is running
unless you use SHOW ALL.


Regards
Gaetano Mendola





Mon, 14 Jun 2004 15:48:40 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Improving postgresql.conf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
  
> Try yourself, I did the experiment changing the cpu_tuple_cost and
> commenting out the cpu_tuple_cost, after sending the SIGHUP to
> postmaster the value remain: 0.005 that is not the default value at
> all.
  
Ducking the added documentation discussion for a minute, I think we
can agree that the commented-default concept is at the least confusing,
at the most broken.
  
> I understand your points below.  However, the group has weighed in the
> direction of clearly showing non-default values and not duplicating
> documentation.  We can change that, but you will need more folks
> agreeing with your direction.
  
How do we do determine this? Perhaps a reasoned discussion on hackers?
 
I'll start, by putting forth the proposal that the default-comment
behavior does more harm than good because it is confusing and broken,
and should be scrapped in favor of a simple "what you see is what you get"
behavior, just like every other configuration file.
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200406151936
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFAz4iBvJuQZxSWSsgRAkO8AKD7t4qdWbeqs7aAuw5ZsQOsKUwGQACfb0/Y
x+vvo6KZ2NgZ9i+4BjIX9yg=
=13P0
-----END PGP SIGNATURE-----



Tue, 15 Jun 2004 23:36:51 -0000
"Greg Sabino Mullane" <greg@turnstep.com>
Re: Improving postgresql.conf
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
> 
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
>   
> > Try yourself, I did the experiment changing the cpu_tuple_cost and
> > commenting out the cpu_tuple_cost, after sending the SIGHUP to
> > postmaster the value remain: 0.005 that is not the default value at
> > all.
>   
> Ducking the added documentation discussion for a minute, I think we
> can agree that the commented-default concept is at the least confusing,
> at the most broken.
>   
> > I understand your points below.  However, the group has weighed in the
> > direction of clearly showing non-default values and not duplicating
> > documentation.  We can change that, but you will need more folks
> > agreeing with your direction.
>   
> How do we do determine this? Perhaps a reasoned discussion on hackers?
>  
> I'll start, by putting forth the proposal that the default-comment
> behavior does more harm than good because it is confusing and broken,
> and should be scrapped in favor of a simple "what you see is what you get"
> behavior, just like every other configuration file.

OK, would other folks share their opinions on this issue?

The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active.  The downside is that it will not
be possible to determine which values were modified from their defaults.

-- 
  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

Tue, 15 Jun 2004 22:21:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Improving postgresql.conf
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The proposal is to remove the comments from postgresql.conf (like
> Apache) so all entries will be active.  The downside is that it will not
> be possible to determine which values were modified from their defaults.

I think the latter is a nontrivial cost.  Perhaps we could address this
by extending the pg_settings view to include the compile-time-default
values for each variable, and then instead of "show us what you did to
postgresql.conf", the standard help request would be
	select * from pg_settings where setting != default_setting;

			regards, tom lane

Tue, 15 Jun 2004 23:27:28 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Improving postgresql.conf 
>>The proposal is to remove the comments from postgresql.conf (like
>>Apache) so all entries will be active.  The downside is that it will not
>>be possible to determine which values were modified from their defaults.

One thing that truly annoys me about postgresql.conf is say I unhash an 
option and set it to something.  Then I reload.  Then I edit the conf 
and hash it out again, then I reload.  Of course, the option still has 
my old value.  This is really annoying and I've wasted lots of time 
trying to figure out what's going on.

Chris


Wed, 16 Jun 2004 12:05:23 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Improving postgresql.conf

On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:

>>> The proposal is to remove the comments from postgresql.conf (like
>>> Apache) so all entries will be active.  The downside is that it will 
>>> not
>>> be possible to determine which values were modified from their 
>>> defaults.
>
> One thing that truly annoys me about postgresql.conf is say I unhash 
> an option and set it to something.  Then I reload.  Then I edit the 
> conf and hash it out again, then I reload.  Of course, the option 
> still has my old value.  This is really annoying and I've wasted lots 
> of time trying to figure out what's going on.

A habit I've gotten into for editing config files that have commented 
defaults is to copy the line with the setting, uncomment the copied 
line, and change it to my setting.

Would it help to have two lines in the config file for each setting, 
one with the default (comment) and one with the actual setting? So for 
example, the postgresql.conf would ship with something like this:

#tcpip_socket = false       #default
tcpip_socket = false

If the user wants to connect via tcp_ip, they can edit it like this:
#tcpip_socket = false       #default
tcpip_socket = true

The default is still there for reference, and they can see what the 
current setting is. Granted, there's redundancy in having the commented 
line and the uncommented line (if I understand the defaults correctly), 
but it might be useful redundancy. Users would have easy reference to 
what the "factory settings" are.

Michael Glaesemann
grzm myrealbox com


Wed, 16 Jun 2004 16:39:16 +0900
Michael Glaesemann <grzm@myrealbox.com>
Re: Improving postgresql.conf

> Would it help to have two lines in the config file for each setting, one 
> with the default (comment) and one with the actual setting? So for 
> example, the postgresql.conf would ship with something like this:
> 
> #tcpip_socket = false       #default
> tcpip_socket = false

Even better, have a postgresql.conf-dist file for reference.

I'm strongly in favour of distribution postresql.conf-large as well, 
with much higher settings for SCSI, 1GM RAM machines, say.  This is 
exactly as MySQL does it and I think it's a great idea.

At least then an admin will notice the file there and say to themselves 
"I wonder what I need to do to configure for a big server, i guess that 
implies that this default postgresql.conf won't perform very well"...

Chris


Wed, 16 Jun 2004 16:06:43 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Improving postgresql.conf
This seems like a nice idea -

It might even be worth targeting a couple pf specific "ranges" - e.g : 
machines with 1G RAM and 4G RAM  ( "medium" are "large" come to mind, I 
know it's a bit like that "other" database product we know of.... but 
that doesn't mean it's necessarily bad!)

Mark

Christopher Kings-Lynne wrote:

>
>
> I'm strongly in favour of distribution postresql.conf-large as well, 
> with much higher settings for SCSI, 1GM RAM machines, say.  This is 
> exactly as MySQL does it and I think it's a great idea.
>
> At least then an admin will notice the file there and say to 
> themselves "I wonder what I need to do to configure for a big server, 
> i guess that implies that this default postgresql.conf won't perform 
> very well"...
>
> Chris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faqs/FAQ.html


Wed, 16 Jun 2004 20:58:51 +1200
Mark Kirkwood <markir@coretech.co.nz>
Re: Improving postgresql.conf
Oh dear, a lot of typos here, hopefully still decipherable... apologies.

Mark


Mark Kirkwood wrote:

> This seems like a nice idea -
>
> It might even be worth targeting a couple pf specific "ranges" - e.g : 
> machines with 1G RAM and 4G RAM  ( "medium" are "large" come to mind, 
> I know it's a bit like that "other" database product we know of.... 
> but that doesn't mean it's necessarily bad!)
>
>

Wed, 16 Jun 2004 21:10:11 +1200
Mark Kirkwood <markir@coretech.co.nz>
Re: Improving postgresql.conf
Christopher Kings-Lynne wrote:
> >>The proposal is to remove the comments from postgresql.conf (like
> >>Apache) so all entries will be active.  The downside is that it will not
> >>be possible to determine which values were modified from their defaults.
> 
> One thing that truly annoys me about postgresql.conf is say I unhash an 
> option and set it to something.  Then I reload.  Then I edit the conf 
> and hash it out again, then I reload.  Of course, the option still has 
> my old value.  This is really annoying and I've wasted lots of time 
> trying to figure out what's going on.

Seems we could easily fix this by reading the config file, marking the
entries we found, and setting all the rest to default values, basically
pretending they were all specified as defaults in the config file.

This does not address the issue of someone changing the default to
another value, then commenting it out, but with the comment I assume
they would want the default, not what is specified in the file.

-- 
  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

Wed, 16 Jun 2004 11:15:42 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Improving postgresql.conf
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Christopher Kings-Lynne wrote:
>> One thing that truly annoys me about postgresql.conf is say I unhash an 
>> option and set it to something.  Then I reload.  Then I edit the conf 
>> and hash it out again, then I reload.  Of course, the option still has 
>> my old value.  This is really annoying and I've wasted lots of time 
>> trying to figure out what's going on.

> Seems we could easily fix this by reading the config file, marking the
> entries we found, and setting all the rest to default values, basically
> pretending they were all specified as defaults in the config file.

We've discussed that and rejected it as a bad idea before.

The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values as comments ...

			regards, tom lane

Wed, 16 Jun 2004 11:19:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Improving postgresql.conf 
On Wednesday 16 June 2004 03:39, Michael Glaesemann wrote:
> On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:
> >>> The proposal is to remove the comments from postgresql.conf (like
> >>> Apache) so all entries will be active.  The downside is that it will
> >>> not
> >>> be possible to determine which values were modified from their
> >>> defaults.
> >
> > One thing that truly annoys me about postgresql.conf is say I unhash
> > an option and set it to something.  Then I reload.  Then I edit the
> > conf and hash it out again, then I reload.  Of course, the option
> > still has my old value.  This is really annoying and I've wasted lots
> > of time trying to figure out what's going on.
>
> A habit I've gotten into for editing config files that have commented
> defaults is to copy the line with the setting, uncomment the copied
> line, and change it to my setting.
>
> Would it help to have two lines in the config file for each setting,
> one with the default (comment) and one with the actual setting? So for
> example, the postgresql.conf would ship with something like this:
>
> #tcpip_socket = false       #default
> tcpip_socket = false
>
> If the user wants to connect via tcp_ip, they can edit it like this:
> #tcpip_socket = false       #default
> tcpip_socket = true
>
> The default is still there for reference, and they can see what the
> current setting is. Granted, there's redundancy in having the commented
> line and the uncommented line (if I understand the defaults correctly),
> but it might be useful redundancy. Users would have easy reference to
> what the "factory settings" are.
>

Misery must love company, because I do the same thing.  Ideally I'd like to go 
further, like pulling the info out of the sgml, but even this would be an 
improvement imho. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Wed, 16 Jun 2004 11:25:07 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: Improving postgresql.conf

Tom Lane <tgl@sss.pgh.pa.us> writes:

> The only real problem I see is that showing all the values as comments
> encourages the idea that you can undo a change by undoing your edit.
> The simple and obvious fix is to not show the values as comments ...

Well even if you don't show them (and it would be most frustrating for users
if you don't) it's certainly expected that commenting something out returns it
to the default value. It's how just about every other piece of software works.
I can lend my own experience as one data point that I was totally surprised
when I found out it didn't work the way I expected.

Note that the current situation means that the same config file means two
different things for initial startup vs reload. I can have a config file that
works fine for months through several reloads, but then be puzzled why my
database doesn't work the same way when i restart the machine and try to start
postgres up... That makes it impossible to test config settings properly
without stopping and restarting the database.

The current situation is that reload isn't really reloading the config file,
it's loading new settings from a file. That's a useful feature but I'm not
convinced it's really all that necessary since you can always load settings
from a command line and it's not hard to load several of them.

Most of the time you use a config file you want to load a consistent set of
settings and the best way to do that is to start from scratch and load the
complete set. Not merge them with whatever settings are in place already.

-- 
greg


16 Jun 2004 12:06:09 -0400
Greg Stark <gsstark@mit.edu>
Re: Improving postgresql.conf
* Greg Stark (gsstark@mit.edu) wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > The only real problem I see is that showing all the values as comments
> > encourages the idea that you can undo a change by undoing your edit.
> > The simple and obvious fix is to not show the values as comments ...
> 
> Well even if you don't show them (and it would be most frustrating for users
> if you don't) it's certainly expected that commenting something out returns it
> to the default value. It's how just about every other piece of software works.
> I can lend my own experience as one data point that I was totally surprised
> when I found out it didn't work the way I expected.

I was suprised too.  I havn't tested yet, but do even other things act
this way?  I'm thinking mainly of pg_hba.conf which I didn't think did,
but not sure.

	Stephen
Wed, 16 Jun 2004 12:16:41 -0400
Stephen Frost <sfrost@snowman.net>
Re: Improving postgresql.conf
Stephen Frost wrote:

>* Greg Stark (gsstark@mit.edu) wrote:
>  
>
>>Tom Lane <tgl@sss.pgh.pa.us> writes:
>>    
>>
>>>The only real problem I see is that showing all the values as comments
>>>encourages the idea that you can undo a change by undoing your edit.
>>>The simple and obvious fix is to not show the values as comments ...
>>>      
>>>
>>Well even if you don't show them (and it would be most frustrating for users
>>if you don't) it's certainly expected that commenting something out returns it
>>to the default value. It's how just about every other piece of software works.
>>I can lend my own experience as one data point that I was totally surprised
>>when I found out it didn't work the way I expected.
>>    
>>
>
>I was suprised too.  I havn't tested yet, but do even other things act
>this way?  I'm thinking mainly of pg_hba.conf which I didn't think did,
>but not sure.
>
>  
>


pg_hba.conf doesn't have any default values ... if you change it all 
your old settings are blown away and the new settings get loaded. 
Commenting out a line does not leave the previous effect of that line in 
place (and it would be a major security problem if it did)

cheers

andrew

Wed, 16 Jun 2004 12:32:01 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Improving postgresql.conf
Greg Stark wrote:

>Tom Lane <tgl@sss.pgh.pa.us> writes:
>
>  
>
>>The only real problem I see is that showing all the values as comments
>>encourages the idea that you can undo a change by undoing your edit.
>>The simple and obvious fix is to not show the values as comments ...
>>    
>>

I agree.
A good way how to describe a config variable is present for 
listen_addresses, which clearly states the default value. Could be even 
shorter, e.g.
port = 5432 # default: 5432

To solve the "commenting out a setting doesn't return to default' 
problem a magic word 'default' could be introduced, forcing to load the 
default setting.

How about *requiring* to set any variable, at least to xxx='default'? 
This would remove any ambiguities (and force to review postgresql.conf 
after upgrading, which is a good idea anyway).

Regards,
Andreas



Wed, 16 Jun 2004 18:52:54 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: Improving postgresql.conf
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> How about *requiring* to set any variable, at least to xxx='default'? 

Don't like that ... we are not in the fascism business here ;-).
How would you enforce it anyway?

The idea of special-casing
	var = default
(with no quotes around 'default') doesn't seem unreasonable, but
then you'd want to show the default in the file, and
	var = default	   # default 42, range 1-100
is maybe getting a bit cluttered.

There is another issue in all this, which is that in the current scheme
of things postgresql.conf settings override postmaster environment
variables, for those few things for which we still accept environment
variables --- it looks like PGPORT, PGDATESTYLE, PGCLIENTENCODING are
the only remaining ones in CVS tip.  If we put noncomment values for
these things into postgresql.conf then the environment variables will
be dead letters; we may as well just remove that code completely.
This might break things for some people.

(Note I am not speaking here of libpq's handling of these variables
on the client side, but of the fact that the *server* takes note of
these environment variables.)

			regards, tom lane

Wed, 16 Jun 2004 13:51:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Improving postgresql.conf 
Tom Lane wrote:

>Andreas Pflug <pgadmin@pse-consulting.de> writes:
>  
>
>>How about *requiring* to set any variable, at least to xxx='default'? 
>>    
>>
>
>Don't like that ... we are not in the fascism business here ;-).
>  
>

Well enforcing setting variables, in the presence of a preconfigured 
file isn't exactly fascism... But I'm not surprised to read your 
objection :-)

>How would you enforce it anyway?
>  
>

Each cfg var would need a 'touched' flag. On startup, an ERROR is 
thrown, on SIGHUP a WARNING. Or just a warning, stating which value is 
actually used?
WARNING: xxx not set, using (default) value yyy.

>The idea of special-casing
>	var = default
>(with no quotes around 'default') doesn't seem unreasonable, but
>then you'd want to show the default in the file, and
>	var = default	   # default 42, range 1-100
>is maybe getting a bit cluttered.
>  
>

In any case, var=default seems valuable.

>There is another issue in all this, which is that in the current scheme
>of things postgresql.conf settings override postmaster environment
>variables, for those few things for which we still accept environment
>variables --- it looks like PGPORT, PGDATESTYLE, PGCLIENTENCODING are
>the only remaining ones in CVS tip.  If we put noncomment values for
>these things into postgresql.conf then the environment variables will
>be dead letters; we may as well just remove that code completely.
>  
>
I'd opt for that.

>This might break things for some people.
>  
>
A check for environment could remain in the code, throwing a warning 
"environment is ignored",  if that's really used.

How about vars overridden on the postmaster command line? Similar issue, 
I believe. Naively, I'd assume that my last instruction (in this case: 
changing postgresql.conf and SIGHUP) would determine processing, which 
is obviously wrong if I read the docs correctly.

Regards,
Andreas



Wed, 16 Jun 2004 20:25:42 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: Improving postgresql.conf
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> How about vars overridden on the postmaster command line? Similar issue, 
> I believe. Naively, I'd assume that my last instruction (in this case: 
> changing postgresql.conf and SIGHUP) would determine processing, which 
> is obviously wrong if I read the docs correctly.

That was another point I was about to make, which is that there are lots
of other reasons why the active value of some config variable might not
be what postgresql.conf says.  We are *not* ripping out the entire GUC
facility just because some people haven't bothered to read the
documentation about it ;-).

Maybe the real problem here is that people think that postgresql.conf
is the place to find out about current settings, and they just need to
be re-educated to look at pg_settings or SHOW ALL instead.

			regards, tom lane

Wed, 16 Jun 2004 14:32:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Improving postgresql.conf 
Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
> > How about vars overridden on the postmaster command line? Similar issue, 
> > I believe. Naively, I'd assume that my last instruction (in this case: 
> > changing postgresql.conf and SIGHUP) would determine processing, which 
> > is obviously wrong if I read the docs correctly.
> 
> That was another point I was about to make, which is that there are lots
> of other reasons why the active value of some config variable might not
> be what postgresql.conf says.  We are *not* ripping out the entire GUC
> facility just because some people haven't bothered to read the
> documentation about it ;-).
> 
> Maybe the real problem here is that people think that postgresql.conf
> is the place to find out about current settings, and they just need to
> be re-educated to look at pg_settings or SHOW ALL instead.

True.  A postmaster arg, per-user or per-db setting, PGOPTIONS value, or
.psqlrc overrides postgresql.conf.

-- 
  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

Wed, 16 Jun 2004 14:43:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Improving postgresql.conf

Andreas Pflug <pgadmin@pse-consulting.de> writes:

> Tom Lane wrote:
> 
> >Andreas Pflug <pgadmin@pse-consulting.de> writes:
> >
> >> How about *requiring* to set any variable, at least to xxx='default'?
> >
> >Don't like that ... we are not in the fascism business here ;-).

It would just make it too hard to add new variables. Nobody would be able to
upgrade without adding those variables to their config files. 

That might make sense for major new features that require hands-on
involvement, but postgres tries to avoid that in favour of having everything
just work without intervention. And you don't want every user to have to
explicitly enable every new feature when upgrading.

Besides, often new variables are just new debugging hooks like
enable_hash_join or such that users shouldn't even have to know about until
they need it.

-- 
greg


16 Jun 2004 14:46:19 -0400
Greg Stark <gsstark@mit.edu>
Re: Improving postgresql.conf
Tom Lane wrote:

>
>That was another point I was about to make, which is that there are lots
>of other reasons why the active value of some config variable might not
>be what postgresql.conf says.  We are *not* ripping out the entire GUC
>facility just because some people haven't bothered to read the
>documentation about it ;-).
>
>Maybe the real problem here is that people think that postgresql.conf
>is the place to find out about current settings, and they just need to
>be re-educated to look at pg_settings or SHOW ALL instead.
>  
>

I agree. This could be supported by tools to show/edit/reload 
postgresql.conf, showing clearly what's default/running/configured.
I propose to support this by backend functions:
pg_configfile_reload()
pg_configfile_get(varname_text)
pg_configfile_set(varname_text, value_text)

to enable client tools (guess which I could think of :-) accessing 
postgresql.conf.

Regards,
Andreas



Wed, 16 Jun 2004 20:49:39 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: Improving postgresql.conf