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 KBbecomes:
## 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.htmlshared_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, Pennsylvania 19073
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
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.
Show quoted text
-----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 KBbecomes:
## 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.htmlshared_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
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
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-confident people can be simple.
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.confWhy? 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/foo1and 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-confident people 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: SHA1We discussed this and thought that it would end up duplicating stuff
already in the docsWhich 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, Pennsylvania 19073
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.
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-----
Import Notes
Reply to msg id not found: 200406101906.i5AJ65k24015@candle.pha.pa.usReference msg id not found: 200406101906.i5AJ65k24015@candle.pha.pa.us | Resolved by subject fallback
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Bruce 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
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: SHA1Bruce 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: SHA1Bruce 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: SHA1Try 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 19073Bruce 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
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:
Show quoted text
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?
Oh dear, a lot of typos here, hopefully still decipherable... apologies.
Mark
Mark Kirkwood wrote:
Show quoted text
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, Pennsylvania 19073Bruce 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 = falseIf the user wants to connect via tcp_ip, they can edit it like this:
#tcpip_socket = false #default
tcpip_socket = trueThe 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
Import Notes
Reply to msg id not found: auto-000005382597@davinci.ethosmedia.comReference msg id not found: auto-000005382597@davinci.ethosmedia.com | Resolved by subject fallback
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-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
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, Pennsylvania 19073Andreas 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