Обсуждение: Improving postgresql.conf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(warning: rehashing of issues ahead)
Sometimes when I talk to technical people about using PostgreSQL,
I get a strong reaction along the lines of "it's ugly, complex, and
hard to set up." While we have gotten better than we used to be,
some of this is still true. I usually press for further details.
One of the top items mentioned is the configuration files,
especially postgresql.conf. Specifically, it is non-standard and
cryptic. 
One thing that would go a long way is to remove the confusing
"default is commented out" behavior. This is ugly and unnecessary:
simply explicitly list every value.
The second thing that would help is better documentation. It doesn't
have to be quite as verbose as the httpd.conf file, but a nice
multi-line explanation of every item in the file, perhaps with a
URL for further information, would be a very nice addition. Moving
the comments above each item, rather than trying to squeeze some of
them next to the parameter, would also make the file more readable
and more consistent. 
For example, this original sample: 
#shared_buffers = 1000          # min 16, at least max_connections*2, 8KB each
#work_mem = 1024                # min 64, size in KB 
becomes: 
## shared_buffers (kilobytes)
## Sets the number of shared memory buffers used by the database server.
## Increasing the number of buffers makes it more likely backends will find
## the information they need in the cache, thus avoiding an expensive operating
## system request. The default is typically 1000, but may be less if your
## kernel settings will not support it. Each buffer is 8192 bytes. The minimum
## value is 16, or twice the value of the 'max_connections' parameter. Settings
## significantly higher than the minimum are usually needed for good performance.
## Values of a few thousand are recommended for production installations.
## URL: http://www.postgresql.org/docs/current/static/runtime-config.html 
shared_buffers = 1000  
## work_mem (kilobytes)
## (Previously known as sort_mem)
## Sets the amount of memory to be used by internal sort operations and hash tables before
## switching to temporary disk files. The default value is 1024 kilobytes (1 MB).
## Note that for a complex query, several sort or hash operations might be running in parallel;
## each one will be allowed to use up to the value set here before it starts to put data
## into temporary files. Also, several running sessions could be doing sort operations
## simultaneously. So the total memory used could be many times the value set here. 
work_mem = 1024
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200406090615
-----BEGIN PGP SIGNATURE-----
iD8DBQFAxuPnvJuQZxSWSsgRAgAtAKDReW6WOREYapbWi61yacBi05im6gCeLrvd
Dj/mlTtUh97C1gHVkJTtLyY=
=J0CZ
-----END PGP SIGNATURE-----

We discussed this and thought that it would end up duplicating stuff
already in the docs, and removing the comments means that you have no
way to know which are being set to non-default values.  Both seem to be
a loss.

Are people saying the Apache config files are easier to use?  I actually
find it quite hard to understand, especially httpd.conf.

One idea that has been floated around is to pull the docs automatically
from SGML and put them in postgresql.conf.  We do that for psql's use of
\help now, so it seems this is possible.

---------------------------------------------------------------------------

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
> 
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
>  
> (warning: rehashing of issues ahead)
>  
> Sometimes when I talk to technical people about using PostgreSQL,
> I get a strong reaction along the lines of "it's ugly, complex, and
> hard to set up." While we have gotten better than we used to be,
> some of this is still true. I usually press for further details.
> One of the top items mentioned is the configuration files,
> especially postgresql.conf. Specifically, it is non-standard and
> cryptic.
>   
> One thing that would go a long way is to remove the confusing
> "default is commented out" behavior. This is ugly and unnecessary:
> simply explicitly list every value.
>  
> The second thing that would help is better documentation. It doesn't
> have to be quite as verbose as the httpd.conf file, but a nice
> multi-line explanation of every item in the file, perhaps with a
> URL for further information, would be a very nice addition. Moving
> the comments above each item, rather than trying to squeeze some of
> them next to the parameter, would also make the file more readable
> and more consistent.
>   
> For example, this original sample:
>   
> #shared_buffers = 1000          # min 16, at least max_connections*2, 8KB each
> #work_mem = 1024                # min 64, size in KB
>   
> becomes:
>   
> ## shared_buffers (kilobytes)
> ## Sets the number of shared memory buffers used by the database server.
> ## Increasing the number of buffers makes it more likely backends will find
> ## the information they need in the cache, thus avoiding an expensive operating
> ## system request. The default is typically 1000, but may be less if your
> ## kernel settings will not support it. Each buffer is 8192 bytes. The minimum
> ## value is 16, or twice the value of the 'max_connections' parameter. Settings
> ## significantly higher than the minimum are usually needed for good performance.
> ## Values of a few thousand are recommended for production installations.
> ## URL: http://www.postgresql.org/docs/current/static/runtime-config.html
>   
> shared_buffers = 1000
>   
>   
> ## work_mem (kilobytes)
> ## (Previously known as sort_mem)
> ## Sets the amount of memory to be used by internal sort operations and hash tables before
> ## switching to temporary disk files. The default value is 1024 kilobytes (1 MB).
> ## Note that for a complex query, several sort or hash operations might be running in parallel;
> ## each one will be allowed to use up to the value set here before it starts to put data
> ## into temporary files. Also, several running sessions could be doing sort operations
> ## simultaneously. So the total memory used could be many times the value set here.
>   
> work_mem = 1024
>  
>  
>  
> - --
> Greg Sabino Mullane greg@turnstep.com
> PGP Key: 0x14964AC8 200406090615
>  
> -----BEGIN PGP SIGNATURE-----
>  
> iD8DBQFAxuPnvJuQZxSWSsgRAgAtAKDReW6WOREYapbWi61yacBi05im6gCeLrvd
> Dj/mlTtUh97C1gHVkJTtLyY=
> =J0CZ
> -----END PGP SIGNATURE-----
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 
[ Decrypting message... End of raw data. ]

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

I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.

If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is. postgresql.conf should do exactly as one would assume it
does, configure postgresql.

Right now it doesn't. Right now it just sets parameters and the "-D" or
PGDATA environment variable *really* configure postgresql. If you do not
know how a machine is setup, you have to look for the install. Hopefuly,
the previous administrator did not have any test directories which would
confuse the search. Sorry, I'm ranting.

In an ideal world, I envision Postgresql having a default location for
postgresql.conf, in this file will be the declarations for where the data
directory is, possible included files, etc. i.e. the stuff I've been
pushing litterally for years. I am not saying that the current behavior
change in any way, what I am saying is that a more world compatible
methodology should be possible.

Once the postgresql.conf file is out of the data directory, you have a new
paradigm from which to work. One could write a setup application, in java
or something, which creates a new postgresql.conf file, right down to
where you want the installed directory to be, and THAT is used by initdb.
The setup application can also provide context sensitive help for each of
the setting. The user may not even *know* that there is such a file as
postgresql.conf.

The application should behave like a control panel of sorts which would
allow you to modify an existing configuration file and optionally restart
the correct postgresql process.

(Obviously, this program can be made to look at other files in other
locations.)

The work flow would be something like this:

run setup application.
Choose volume and directory for database.
set various options
press OK
standard "are you sure" dialog.
run initdb with variables,

In linux, freebsd, or Windows, have the option to start server at system
start.

This is all basically doable right now. Granted we have to hammer out a
few details in my configuration patch, but there are no show stoppers that
I can see. I even have a Windows application which will start and monitor
a cygwin PostgreSQL. It should be easily modified for a mingwin version.

That, IMHO, would *really* make PostgreSQL easy, almost brainless to
install and use.

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> (warning: rehashing of issues ahead)
>
> Sometimes when I talk to technical people about using PostgreSQL,
> I get a strong reaction along the lines of "it's ugly, complex, and
> hard to set up." While we have gotten better than we used to be,
> some of this is still true. I usually press for further details.
> One of the top items mentioned is the configuration files,
> especially postgresql.conf. Specifically, it is non-standard and
> cryptic.
>
> One thing that would go a long way is to remove the confusing
> "default is commented out" behavior. This is ugly and unnecessary:
> simply explicitly list every value.
>
> The second thing that would help is better documentation. It doesn't
> have to be quite as verbose as the httpd.conf file, but a nice
> multi-line explanation of every item in the file, perhaps with a
> URL for further information, would be a very nice addition. Moving
> the comments above each item, rather than trying to squeeze some of
> them next to the parameter, would also make the file more readable
> and more consistent.
>
> For example, this original sample:
>
> #shared_buffers = 1000          # min 16, at least max_connections*2, 8KB
> each
> #work_mem = 1024                # min 64, size in KB
>
> becomes:
>
> ## shared_buffers (kilobytes)
> ## Sets the number of shared memory buffers used by the database server.
> ## Increasing the number of buffers makes it more likely backends will
> find
> ## the information they need in the cache, thus avoiding an expensive
> operating
> ## system request. The default is typically 1000, but may be less if your
> ## kernel settings will not support it. Each buffer is 8192 bytes. The
> minimum
> ## value is 16, or twice the value of the 'max_connections' parameter.
> Settings
> ## significantly higher than the minimum are usually needed for good
> performance.
> ## Values of a few thousand are recommended for production installations.
> ## URL: http://www.postgresql.org/docs/current/static/runtime-config.html
>
> shared_buffers = 1000
>
>
> ## work_mem (kilobytes)
> ## (Previously known as sort_mem)
> ## Sets the amount of memory to be used by internal sort operations and
> hash tables before
> ## switching to temporary disk files. The default value is 1024 kilobytes
> (1 MB).
> ## Note that for a complex query, several sort or hash operations might be
> running in parallel;
> ## each one will be allowed to use up to the value set here before it
> starts to put data
> ## into temporary files. Also, several running sessions could be doing
> sort operations
> ## simultaneously. So the total memory used could be many times the value
> set here.
>
> work_mem = 1024
>
>
>
> - --
> Greg Sabino Mullane greg@turnstep.com
> PGP Key: 0x14964AC8 200406090615
>
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFAxuPnvJuQZxSWSsgRAgAtAKDReW6WOREYapbWi61yacBi05im6gCeLrvd
> Dj/mlTtUh97C1gHVkJTtLyY=
> =J0CZ
> -----END PGP SIGNATURE-----
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

pgsql@mohawksoft.com wrote:

> I have a LOT of opinions about postgresql.conf, and frankly, I think more
> comments are not where the problems lie.
> 
> If you *really* want to make configuring postgresql easier,
> postgresql.conf HAS to live outside the data directory and specify where
> everything is. postgresql.conf should do exactly as one would assume it
> does, configure postgresql.
> 
> Right now it doesn't. Right now it just sets parameters and the "-D" or
> PGDATA environment variable *really* configure postgresql. If you do not
> know how a machine is setup, you have to look for the install. Hopefuly,
> the previous administrator did not have any test directories which would
> confuse the search. Sorry, I'm ranting.
> 
> In an ideal world, I envision Postgresql having a default location for
> postgresql.conf, in this file will be the declarations for where the data
> directory is, possible included files, etc. i.e. the stuff I've been
> pushing litterally for years. I am not saying that the current behavior
> change in any way, what I am saying is that a more world compatible
> methodology should be possible.
> 
> Once the postgresql.conf file is out of the data directory, you have a new
> paradigm from which to work. One could write a setup application, in java
> or something, which creates a new postgresql.conf file, right down to
> where you want the installed directory to be, and THAT is used by initdb.
> The setup application can also provide context sensitive help for each of
> the setting. The user may not even *know* that there is such a file as
> postgresql.conf.

Well, the statement 'postgresql.conf outside data directory' isn't going to win 
I think.

postgresql.conf is a cluster configuration file. I remember previous discussion 
on this and I agree with that a cluster configuration file should remain in 
cluster itself.

Let me put it in a different way. What you are asking is a service configuration 
file. It is *not* same as current postgresql configuration file. It will/should 
be unique to a perticular installation of postgresql. i.e. something like 
/etc/postgresql/7.4.2/service.conf

I think it makes a lot of sense then. It would allow to maitain different 
clusters, like in another thread where OP wanted different locales/collation. 
And it will still allow multiple versions of postgresql to be installed.

I remember chasing mandrake couple of years ago for not to make postgresql 
database live in /var/lib/data... but to make it configurable. It didn't go 
anywhere though.

I think it is a rather good idea to add service configuration to default 
postgresql install. May be linux distro. vendors can customize thr. the init 
scripts.

Also pulling postgresql.conf out of cluster has a drawback. All the clusters 
would have to share same tuning parameters which is not exactly ideal. If we 
define a services file with multiple clusters we woudl still provide ultimate 
control to the DBA/system admin.

Just a thought..
 Shridhar

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> One idea that has been floated around is to pull the docs automatically
> from SGML and put them in postgresql.conf.

In theory, postgresql.conf.sample could be a generated file: pull the
docs from SGML and the default values from the GUC tables.  However I'm
of the same opinion Bruce mentioned, that duplicating the docs in the
file isn't an improvement.  Perhaps it would help to put an explicit
pointer to the docs at the top of the file?
        regards, tom lane

On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
> 
> Well, the statement 'postgresql.conf outside data directory' isn't going to 
> win I think.

One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have the configuration
somewhere else. Ideally, only the absolute minimum of parameters
needed to start the server ought to be in the external configuration.
Everything else may happily reside within the database storage.

> Let me put it in a different way. What you are asking is a service 
> configuration file. It is *not* same as current postgresql configuration 
> file. It will/should be unique to a perticular installation of postgresql. 
> i.e. something like /etc/postgresql/7.4.2/service.conf

Why? The administrator may want to run second cluster on the same
machine, share a couple of options using "include" directive while
preserving separate configuration, including the location of data
store, for things that should be different for each of these
clusters.

> I think it is a rather good idea to add service configuration to default 

What is that "service" you mention?

> Also pulling postgresql.conf out of cluster has a drawback. All the 
> clusters would have to share same tuning parameters which is not exactly 
> ideal.

Why would they _have_ to? Pulling postgresql.conf out of cluster only
means that the file resides somewhere else and in it the location of
the data directory is specified. It does not mandate there will only
be one cluster and it does not mean that each cluster cannot have
completely different configuration file.

-- 
------------------------------------------------------------------------Honza Pazdziora | adelton@fi.muni.cz |
http://www.fi.muni.cz/~adelton/.project:Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...    Only
self-confidentpeople can be simple.
 

Greg Sabino Mullane wrote:

>(warning: rehashing of issues ahead)
> 
>[snipped: suggestion to have much more documentation in sample postgresql.conf]
>  
>

Wasn't RedHat working on a configuration utility for Postgres? That 
seems to me like a much more productive way to go.

cheers

andrew

Honza Pazdziora wrote:

> On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
> 
>>Well, the statement 'postgresql.conf outside data directory' isn't going to 
>>win I think.
> One day there won't be any data directory because the data will be
> on raw partitions. Then you will _have_ to have the configuration
> somewhere else. Ideally, only the absolute minimum of parameters
> needed to start the server ought to be in the external configuration.
> Everything else may happily reside within the database storage.

Given that postgresql by design does not outsmart OS in any overlapping 
functionality, I doubt we would see raw storage anytime soon but anyways..


>>Let me put it in a different way. What you are asking is a service 
>>configuration file. It is *not* same as current postgresql configuration 
>>file. It will/should be unique to a perticular installation of postgresql. 
>>i.e. something like /etc/postgresql/7.4.2/service.conf
> Why? The administrator may want to run second cluster on the same
> machine, share a couple of options using "include" directive while
> preserving separate configuration, including the location of data
> store, for things that should be different for each of these
> clusters.

Well that is easy. In the service file just say

[Cluster1] datapath=/data/foo

[Cluster2] datapath=/data/foo1

and postgresql.conf could still reside inside each cluster to provide specific 
configuration.

Thenhave a script which can say 'service postgresql cluster1 start'

>>I think it is a rather good idea to add service configuration to default 
> What is that "service" you mention?

Postgresql as a database server is a service. A cluster is an service instance. 
A service configuration file documents all service instances and their 
parameters required for all tuning and control purposes. Add a possibility of 
multiple versions of postgresql on same box. That sums it up pretty well..

>>Also pulling postgresql.conf out of cluster has a drawback. All the 
>>clusters would have to share same tuning parameters which is not exactly 
>>ideal.
> Why would they _have_ to? Pulling postgresql.conf out of cluster only
> means that the file resides somewhere else and in it the location of
> the data directory is specified. It does not mandate there will only
> be one cluster and it does not mean that each cluster cannot have
> completely different configuration file.

Well, I wish I could have some archives link handy but suffice to say that Tom 
has rejected this idea many times before..
 Shridhar

On Wed, Jun 09, 2004 at 09:13:05PM +0530, Shridhar Daithankar wrote:
> 
> Well that is easy. In the service file just say
> 
> [Cluster1]
>  datapath=/data/foo
> 
> [Cluster2]
>  datapath=/data/foo1
> 
> and postgresql.conf could still reside inside each cluster to provide 
> specific configuration.
> 
> Thenhave a script which can say 'service postgresql cluster1 start'

This is awfull way of doing configuration. Why should different
installation share anything, in one file? Running
/usr/bin/pg_ctl -C /etc/postgres.isp1.conf start

seems much more maintainable. And /etc/postgres.isp1.conf can specify
that the data files are in /bigdisk/data/isp1x or wherever you
please.

> Postgresql as a database server is a service. A cluster is an service 
> instance. A service configuration file documents all service instances and 
> their parameters required for all tuning and control purposes. Add a 
> possibility of multiple versions of postgresql on same box. That sums it up 

One file does not add possibility of multiple versions of postgresql
on same box, it merely makes it harder.

> Well, I wish I could have some archives link handy but suffice to say that 
> Tom has rejected this idea many times before..

That does not necessarily mean the idea is broken. Tom's main
objection (IIRC) was that he needs to be able to have multiple
postgresqls on one machine. That can easily be achieved, either by
specifying datadirectory in the configuration file, or even defaulting
to the same directory where the .conf file is stored when no
datadirectory option is used.

-- 
------------------------------------------------------------------------Honza Pazdziora | adelton@fi.muni.cz |
http://www.fi.muni.cz/~adelton/.project:Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...    Only
self-confidentpeople can be simple.
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> We discussed this and thought that it would end up duplicating stuff
> already in the docs
Which is fine. Keeping some documentation in the file itself is a
necessity. For example, we've changed "sort_mem" to "work_mem".
There should at the least be a note to this effect in the postgresql.conf
file. Better yet, there should be a brief explanation of what each of
the parameters _means_ and what each one _does_. It does not have to go
into detail, but there should be enough language to remind somebody what
exactly the sometimes cryptically named parameter does. The name alone
is not enough. When in doubt, it is always better to err on the side
of more verbose documentation.
> and removing the comments means that you have no way to know which are
> being set to non-default values.
This seems a non-issue to me. The end-user does not really care so much
about what is "default" so much as what it is right now. We are overloading
the "#" operator, so to speak, by making it not only a documentation
markup, but by making it a "set default because it is commented out." What
happens when somebody changes the sort_mem to something, and then comments
it out to "turn it back to the default"? The next person looking at the file
is not going to know what the setting is, because instead of the default being
in the documentation part of the file, it is in the commented-out parameter,
and it is now wrong. Far better to explicitly set every parameter. You can
then go into the file and know exactly what each parameter is set to.
> Are people saying the Apache config files are easier to use?  I actually
> find it quite hard to understand, especially httpd.conf.
It is certainly well documented. You can step into it for the first time
and have a relatively complete understanding of what each setting does.
It's also laid out logically, but we have mostly addressed this in the
last big rearrangement of postgresql.conf that happened a few months ago.
> One idea that has been floated around is to pull the docs automatically
> from SGML and put them in postgresql.conf.  We do that for psql's use of
> \help now, so it seems this is possible.
I'm not sure this is the way to go. The SGML should be more detailed, and
also assumes that you are reading it in a different context than from within
the configuration file.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200406100751
-----BEGIN PGP SIGNATURE-----
iD8DBQFAyE0rvJuQZxSWSsgRAqL3AJ0eR28O8LyWV3Kn5wgMtggqJi8/nACeI/JC
onWV778+vewEdBeAI+EYOkw=
=/wqn
-----END PGP SIGNATURE-----

Dear Greg,

> > One idea that has been floated around is to pull the docs automatically
> > from SGML and put them in postgresql.conf.  We do that for psql's use of
> > \help now, so it seems this is possible.
>
> I'm not sure this is the way to go. The SGML should be more detailed, and
> also assumes that you are reading it in a different context than from within
> the configuration file.

As for the level defail, I guess the idea is to extract only a relevant
part of the sgml doc: parameter name, summary and advices, default value.
Sure the doc can contains more than that, but at least this should be
available.

As for the context, I think that is is factual enough so as to be able to
write documentation that would fit both the doc and the configuration
file.

-- 
Fabien Coelho - coelho@cri.ensmp.fr

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.

---------------------------------------------------------------------------

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
> 
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
>  
> > We discussed this and thought that it would end up duplicating stuff
> > already in the docs
>  
> Which is fine. Keeping some documentation in the file itself is a
> necessity. For example, we've changed "sort_mem" to "work_mem".
> There should at the least be a note to this effect in the postgresql.conf
> file. Better yet, there should be a brief explanation of what each of
> the parameters _means_ and what each one _does_. It does not have to go
> into detail, but there should be enough language to remind somebody what
> exactly the sometimes cryptically named parameter does. The name alone
> is not enough. When in doubt, it is always better to err on the side
> of more verbose documentation.
>  
> > and removing the comments means that you have no way to know which are
> > being set to non-default values.
>  
> This seems a non-issue to me. The end-user does not really care so much
> about what is "default" so much as what it is right now. We are overloading
> the "#" operator, so to speak, by making it not only a documentation
> markup, but by making it a "set default because it is commented out." What
> happens when somebody changes the sort_mem to something, and then comments
> it out to "turn it back to the default"? The next person looking at the file
> is not going to know what the setting is, because instead of the default being
> in the documentation part of the file, it is in the commented-out parameter,
> and it is now wrong. Far better to explicitly set every parameter. You can
> then go into the file and know exactly what each parameter is set to.
>  
> > Are people saying the Apache config files are easier to use?  I actually
> > find it quite hard to understand, especially httpd.conf.
>  
> It is certainly well documented. You can step into it for the first time
> and have a relatively complete understanding of what each setting does.
> It's also laid out logically, but we have mostly addressed this in the
> last big rearrangement of postgresql.conf that happened a few months ago.
>  
> > One idea that has been floated around is to pull the docs automatically
> > from SGML and put them in postgresql.conf.  We do that for psql's use of
> > \help now, so it seems this is possible.
>  
> I'm not sure this is the way to go. The SGML should be more detailed, and
> also assumes that you are reading it in a different context than from within
> the configuration file.
>  
> - --
> Greg Sabino Mullane greg@turnstep.com
> PGP Key: 0x14964AC8 200406100751
>  
> -----BEGIN PGP SIGNATURE-----
>  
> iD8DBQFAyE0rvJuQZxSWSsgRAqL3AJ0eR28O8LyWV3Kn5wgMtggqJi8/nACeI/JC
> onWV778+vewEdBeAI+EYOkw=
> =/wqn
> -----END PGP SIGNATURE-----
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 
[ Decrypting message... End of raw data. ]

--  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 wrote:
> I understand your points below.  However, the group has weighed in the> direction of clearly showing non-default
valuesand 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.


Regards
Gaetano Mendola

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

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

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.

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

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

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

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 beselect * from pg_settings where setting != default_setting;
        regards, tom lane

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

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

> 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

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

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

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

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

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

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

* 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

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

Tom, folks:

> 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'll say!    I've been testing PostgreSQL.conf settings, writing docs for 
them, etc. for several years now and this is the first I was aware that 
commenting out lines would not reset the defaults.   Mind you, that's partly 
because I don't think I've ever re-commented anything; but certainly if I can 
be confused about this, then the majority of our users are likewise confused.

My thoughts:

1) Uncomment everything in the postgresql.conf file.   As long as we have 
commented out values, people will think that commented == default.

2) I think the easiest way to let people know the defaults for .conf is to 
have initdb generate a 2nd file called postgresql.conf.defaults.   This will 
allow them to compare and reset -- or even copy over -- if things get too 
messed up.   The second way is to list the defaults in our documentation.

3) Like Bruce, I think it would be nifty to have a postgresql.conf.large file 
to give people the hint about tuning for modern servers.   However, the 
problem is that many settings hinge on the exact machine configuration; i.e. 
the specific amount of memory, whether or not the DB is bigger than RAM, how 
fast the disk array is, etc.   Further, some settings vary pretty strongly 
between types of database; the config file for a transaction-processing DB is 
quite different from an OLAP server.Finally, there's the issue that we'll need significant testing on 7.5 before 
we're confident what the best memory settings *are*.    Jan's work changes 
the balance between reserved and kernel memory significantly.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

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

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-casingvar = default
(with no quotes around 'default') doesn't seem unreasonable, but
then you'd want to show the default in the file, andvar = 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

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

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

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

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

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