Re: TODO questions

While marking up TODO for potential new-hacker items I've run across
some items that probably need more explanation:

o Allow commenting of variables in postgresql.conf to restore them
to defaults

This doesn't work already?

* Allow triggers to be disabled [trigger]

Isn't this going to be in 8.1?

* SQL*Net listener that makes PostgreSQL appear as an Oracle database
to clients

Any reason not to do this for other databases; notably MySQL?

o Do VACUUM FULL if table is nearly empty?

Since that results in an exclusive table lock (which is vastly different
from regular vacuum), wouldn't it be better to just throw a warning?

* Reduce WAL traffic so only modified values are written rather than
entire rows?

Shouldn't this be marked as depending on eliminate need to write full
pages? (At least ISTM it won't do any good as long as we're writing full
pages)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461

Jim C. Nasby wrote:
> While marking up TODO for potential new-hacker items I've run across
> some items that probably need more explanation:
>
> o Allow commenting of variables in postgresql.conf to restore them
> to defaults
>
> This doesn't work already?

The idea here is the when you comment something out, it should restore
its default. Right now it keeps the previously uncommented out value,
which confuses people.

New text is:

o Allow commenting of variables in postgresql.conf to restore them
to defaults

Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.

> * Allow triggers to be disabled [trigger]
>
> Isn't this going to be in 8.1?

Yes, just marked it as done because it went into CVS 12 hours ago.

> * SQL*Net listener that makes PostgreSQL appear as an Oracle database
> to clients
>
> Any reason not to do this for other databases; notably MySQL?

I suppose, but no one has asked for it, while they have for Oracle.
>
> o Do VACUUM FULL if table is nearly empty?
>
> Since that results in an exclusive table lock (which is vastly different
> from regular vacuum), wouldn't it be better to just throw a warning?

Good point. I guess that's why the question mark was there. New text:

o Suggest a VACUUM FULL if table is nearly empty

> * Reduce WAL traffic so only modified values are written rather than
> entire rows?
>
> Shouldn't this be marked as depending on eliminate need to write full
> pages? (At least ISTM it won't do any good as long as we're writing full
> pages)

Not really --- the per-row writes and the full page writes are two
different operations for two different purposes. The first is for WAL
crash recovery, the second is to prevent partial page writes.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

> The idea here is the when you comment something out, it should restore
> its default. Right now it keeps the previously uncommented out value,
> which confuses people.

I think it will continue to confuse people. I will bring up the idea again
here of simply uncommenting *all* settings, which would make things very
clear and also make our conf file work like most others.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200508241037
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkMMhngACgkQvJuQZxSWSsh6HQCgmltyTuSzRwUyP+y0IRZbWIpR
eN0AoKGF5uFhtD3cM74I7mTfHawoCDLo
=gBav
-----END PGP SIGNATURE-----

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Jim C. Nasby wrote:
>> o Allow commenting of variables in postgresql.conf to restore them
>> to defaults
>>
>> This doesn't work already?

> The idea here is the when you comment something out, it should restore
> its default. Right now it keeps the previously uncommented out value,
> which confuses people.

But the contrary position is that a comment is a comment, not something
that should act to change the state of the postmaster.

It's probably worth pointing out that there's not consensus about all
of the TODO items, particularly not the ones Bruce has marked with
question marks.

regards, tom lane

>>The idea here is the when you comment something out, it should restore
>>its default. Right now it keeps the previously uncommented out value,
>>which confuses people.
>>
>>
>
>But the contrary position is that a comment is a comment, not something
>that should act to change the state of the postmaster.
>
>
Not in any conf I have ever seen. If I comment out a parameter
I expect that the parameter will either be disabled or set to the
default depending on the parameter.

#fsync = false

Should mean:

fsync = false

--

fsync = true

Should mean:

fsync = true

--

#fsync = true:

Should mean:

fsync = false

If false is the default value.

--

Sincerely,

Joshua D. Drake

>It's probably worth pointing out that there's not consensus about all
>of the TODO items, particularly not the ones Bruce has marked with
>question marks.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>

Tom Lane wrote:

>But the contrary position is that a comment is a comment, not something
>that should act to change the state of the postmaster.
>
>
>
>

I think that's a mis-statement of the issue, as I understand it, which
seems to me to be this: Should the absence of an explicit setting in the
config file result in keeping the previous setting of the item or in
resetting it to the default value? Of course, the question is made more
complex by the fact that you can set things by means other than the
config file, and having your settings revert to some default might
indeed cause some surprises. Notwithstanding that, I'm fairly firmly in
the revert to default camp - I think on balance it conforms to the
principle of least surprise.

cheers

andrew

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
>>Jim C. Nasby wrote:
>>
>>>o Allow commenting of variables in postgresql.conf to restore them
>>>to defaults
>>>
>>>This doesn't work already?
>
>
>>The idea here is the when you comment something out, it should restore
>>its default. Right now it keeps the previously uncommented out value,
>>which confuses people.
>
>
> But the contrary position is that a comment is a comment, not something
> that should act to change the state of the postmaster.
>

I understand what you mean, but to be fair, it's not the comment that is
changing the behavior of the postmaster. Rather, it's the absence of a
setting in the configuration file that would suggest using the default.

It seems to me like a question of whether the configuration file should
be treated as:
a) the set of options for the postmaster
b) a set of changes to the options for the postmaster

The current behavior is (b), but many think (a) is more intuitive in the
context of a configuration file. Perhaps (b) would be more intuitive if
it were in the context of (for example) an admin tool that took options
on standard input.

Regards,
Jeff Davis

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
> > The idea here is the when you comment something out, it should restore
> > its default. Right now it keeps the previously uncommented out value,
> > which confuses people.
>
> But the contrary position is that a comment is a comment, not something
> that should act to change the state of the postmaster.

As someone else said I think there's a fundamental difference here on what
"reloading" means.

In every other system I've seen, when you "reload" a config file the system
goes through the exact same process (semantically at least) that it does when
starting up. Ie, it start with a fresh slate of defaults and loads the config
file which sets parameters and overrides those defaults.

The Postgres way is that it remembers the old values and loads the config
files on top of that. You end up with a situation equivalent to having the new
config file tacked onto the old one.

The problem with the Postgres semantics is that you end up with a system in a
state that isn't represented in either the new config file or the old one.
This means if you restart Postgres will come up in a different state from what
was running.

The conventional semantics give the sysadmin a nice guarantee that he or she
can reload the config file and if it works then he can be confident that the
server is using the same configuration that it will be using after a restart.

I fear a lot of sysadmins after being bitten by this confusion once will
decide that it's unsafe to simply reload config files in Postgres and it's
necessary to stop and start the server to be sure the new config file is
correct and won't cause problems after a subsequent restart.

--
greg

On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote:
> In every other system I've seen, when you "reload" a config file the system
> goes through the exact same process (semantically at least) that it does when
> starting up. Ie, it start with a fresh slate of defaults and loads the config
> file which sets parameters and overrides those defaults.

I think this is a good summary of the desired behavior, and that it
should be added to the TODO description.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461

OK, TODO updated:

o %Allow commenting of variables in postgresql.conf to restore them
to defaults

Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.
Logically, a reload should set the same values as a
server restart.

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

Jim C. Nasby wrote:
> On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote:
> > In every other system I've seen, when you "reload" a config file the system
> > goes through the exact same process (semantically at least) that it does when
> > starting up. Ie, it start with a fresh slate of defaults and loads the config
> > file which sets parameters and overrides those defaults.
>
> I think this is a good summary of the desired behavior, and that it
> should be added to the TODO description.
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com 512-569-9461
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> writes:
> OK, TODO updated:
> o %Allow commenting of variables in postgresql.conf to restore them
> to defaults

> Currently, if a variable is commented out, it keeps the
> previous uncommented value until a server restarted.
> Logically, a reload should set the same values as a
> server restart.

That all sounds nice, but unless you intend to fix all the constraints
that force some values to be set-only-at-postmaster-start, it's never
going to be possible to promise that a reload has the same effect as
restarting the server. We could do this for values that are not
PGC_POSTMASTER, but the argument given above for doing it is bogus.

regards, tom lane

OK, additional sentence removed.

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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > OK, TODO updated:
> > o %Allow commenting of variables in postgresql.conf to restore them
> > to defaults
>
> > Currently, if a variable is commented out, it keeps the
> > previous uncommented value until a server restarted.
> > Logically, a reload should set the same values as a
> > server restart.
>
> That all sounds nice, but unless you intend to fix all the constraints
> that force some values to be set-only-at-postmaster-start, it's never
> going to be possible to promise that a reload has the same effect as
> restarting the server. We could do this for values that are not
> PGC_POSTMASTER, but the argument given above for doing it is bogus.
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

I've always been of the impression that this idea just wont work. For
example, if I set shared_buffers to some number, start my database, then
comment the line out and "reload" my conf file, it just isnt going to reset
to the default. (Or at least to make it do so requires a *lot* more work than
just modifing the guc / conf file mechanisms).

IMHO the suggestion to just uncomment out all of the variables to begin with
would cut down on confusion a great deal and actually be easy to implement,
and as such is probably the way to go for now.

Robert Treat

On Wednesday 24 August 2005 15:43, Bruce Momjian wrote:
> OK, TODO updated:
>
> o %Allow commenting of variables in postgresql.conf to restore them
> to defaults
>
> Currently, if a variable is commented out, it keeps the
> previous uncommented value until a server restarted.
> Logically, a reload should set the same values as a
> server restart.
>
>
> ---------------------------------------------------------------------------
>
> Jim C. Nasby wrote:
> > On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote:
> > > In every other system I've seen, when you "reload" a config file the
> > > system goes through the exact same process (semantically at least) that
> > > it does when starting up. Ie, it start with a fresh slate of defaults
> > > and loads the config file which sets parameters and overrides those
> > > defaults.
> >
> > I think this is a good summary of the desired behavior, and that it
> > should be added to the TODO description.
> > --
> > Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> > Pervasive Software http://pervasive.com 512-569-9461

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

Robert Treat wrote:
> I've always been of the impression that this idea just wont work. For
> example, if I set shared_buffers to some number, start my database, then
> comment the line out and "reload" my conf file, it just isnt going to reset
> to the default. (Or at least to make it do so requires a *lot* more work than
> just modifing the guc / conf file mechanisms).

True, but you can't modify shared_buffers anyway unless you restart, so
people should realize that.

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

> IMHO the suggestion to just uncomment out all of the variables to begin with
> would cut down on confusion a great deal and actually be easy to implement,
> and as such is probably the way to go for now.
>
> Robert Treat
>
> On Wednesday 24 August 2005 15:43, Bruce Momjian wrote:
> > OK, TODO updated:
> >
> > o %Allow commenting of variables in postgresql.conf to restore them
> > to defaults
> >
> > Currently, if a variable is commented out, it keeps the
> > previous uncommented value until a server restarted.
> > Logically, a reload should set the same values as a
> > server restart.
> >
> >
> > ---------------------------------------------------------------------------
> >
> > Jim C. Nasby wrote:
> > > On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote:
> > > > In every other system I've seen, when you "reload" a config file the
> > > > system goes through the exact same process (semantically at least) that
> > > > it does when starting up. Ie, it start with a fresh slate of defaults
> > > > and loads the config file which sets parameters and overrides those
> > > > defaults.
> > >
> > > I think this is a good summary of the desired behavior, and that it
> > > should be added to the TODO description.
> > > --
> > > Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> > > Pervasive Software http://pervasive.com 512-569-9461
>
> --
> Robert Treat
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> That all sounds nice, but unless you intend to fix all the constraints
> that force some values to be set-only-at-postmaster-start, it's never
> going to be possible to promise that a reload has the same effect as
> restarting the server. We could do this for values that are not
> PGC_POSTMASTER, but the argument given above for doing it is bogus.

Well that's true, that's a limitation of Postgres's reloading config files.
Certainly I think it should be a goal to avoid any such guc variables where
it's worth the effort. That doesn't mean you have to make the "problem" worse
and go in a completely different direction.

I would say it would be reasonable to print a warning if loading the new
config file results in a different value for any guc variable that can't be
changed.

If that's too awkward then at least it would be nice to put a warning line in
the initial default config file to mark any such guc variables.

--
greg

Joshua D. Drake wrote:
>>> ...when you comment something out, it should restore
>> ...the contrary position is that a comment is a comment...
> ...If I comment out a parameter I expect...

The most unambiguous behavior would be to not have
commented out values in the config file at all.

If someone wants to change a value and keep a reminder of
what the old value was, he's welcome to comment out the
original line himself. (assuming that was the thinking
behind commenting them out in the first place)

On Wed, Aug 24, 2005 at 10:03:28PM -0700, Ron Mayer wrote:
> Joshua D. Drake wrote:
> >>>...when you comment something out, it should restore
> >>...the contrary position is that a comment is a comment...
> >...If I comment out a parameter I expect...
>
>
> The most unambiguous behavior would be to not have
> commented out values in the config file at all.
>
> If someone wants to change a value and keep a reminder of
> what the old value was, he's welcome to comment out the
> original line himself. (assuming that was the thinking
> behind commenting them out in the first place)

That only makes sense if you also remove the concept of default values;
something I don't think we want to do.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461

Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> The most unambiguous behavior would be to not have
> commented out values in the config file at all.

Yeah, Robert Treat suggested that upthread, and I think it's been pushed
by others too.

The only argument I can see against it is that it'll take longer for the
system to process such a file; but do we really care about a few more
microseconds to respond to SIGHUP?

This does not address the problem that changing PGC_POSTMASTER values in
the file won't do anything without a postmaster restart. Greg Stark's
suggestion of marking each PGC_POSTMASTER variable with a warning
comment in postgresql.conf seems reasonable to me, though.

So, the low-tech solution to these gripes seems to be:
* uncomment all the entries in postgresql.conf
* add comments to flag the values that can't be changed by SIGHUP

Can we agree on taking these measures?

regards, tom lane

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> On Wed, Aug 24, 2005 at 10:03:28PM -0700, Ron Mayer wrote:
>> The most unambiguous behavior would be to not have
>> commented out values in the config file at all.

> That only makes sense if you also remove the concept of default values;
> something I don't think we want to do.

Well, the hardwired default values are really only there to ensure
sanity if the config file fails to provide values. We already have to
make sure that the hardwired defaults match what it says in
postgresql.conf.sample, if only for documentation reasons. So I'm
not seeing a strong argument here.

regards, tom lane

On Thu, 25 Aug 2005, Tom Lane wrote:

> Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
>> The most unambiguous behavior would be to not have
>> commented out values in the config file at all.
>
> Yeah, Robert Treat suggested that upthread, and I think it's been pushed
> by others too.
>
> The only argument I can see against it is that it'll take longer for the
> system to process such a file; but do we really care about a few more
> microseconds to respond to SIGHUP?

This has probably been mentioned already, but it makes it much harder to
see which values have been altered from their default values. At the very
least, the default values should be in the comments together with the min
and max values.

Also, suppose that we change the default value of parameter in a new
release. That change wouldn't be picked up by upgraders that keep using
their old config file. I don't know how big an issue that is in practice.

We could have a special value DEFAULT that would mean that the variable
should be set to it's default. The config file would look like this:

shared_buffers = DEFAULT # default 1000
work_mem = DEFAULT # default 1024
...

That would avoid the surprise that commenting a line and reloading
doesn't actually do anything, while also making it obvious which values
have been modified.

> This does not address the problem that changing PGC_POSTMASTER values in
> the file won't do anything without a postmaster restart. Greg Stark's
> suggestion of marking each PGC_POSTMASTER variable with a warning
> comment in postgresql.conf seems reasonable to me, though.

If we keep the current behaviour, could we also issue a runtime warning if
a PGC_POSTMASTER variable was changed? Also, could we issue a warning if a
variable is not at it's default value, but is missing from the new
config file?

- Heikki

Tom Lane wrote:

> So, the low-tech solution to these gripes seems to be:
> * uncomment all the entries in postgresql.conf
> * add comments to flag the values that can't be changed by SIGHUP
>
> Can we agree on taking these measures?

Doesn't this still mean that a SIGHUP may give you a different
configuration to a full restart, even if you don't touch any of the
values that can't be changed via SIGHUP?

Perhaps we could stick with the current commented-out-defaults scheme if
SIGHUP reset all settings to their compiled-in defaults before rereading
the config file, i.e. the same logic as normal startup would do (except
for those cases where we can't change a setting at runtime).

-O

On Thu, Aug 25, 2005 at 12:09:21 +0300,
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> This has probably been mentioned already, but it makes it much harder to
> see which values have been altered from their default values. At the very
> least, the default values should be in the comments together with the min
> and max values.

I think it can be expected that people who care will comment out the original
line and add a new one for the changed setting. Or if worse comes to worse
they can get a fresh copy of postgresql.conf and run diff.

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> Tom Lane wrote:
> >But the contrary position is that a comment is a comment, not something
> >that should act to change the state of the postmaster.
>
> I think that's a mis-statement of the issue, as I understand it, which
> seems to me to be this: Should the absence of an explicit setting in the
> config file result in keeping the previous setting of the item or in
> resetting it to the default value? Of course, the question is made more
> complex by the fact that you can set things by means other than the
> config file, and having your settings revert to some default might
> indeed cause some surprises. Notwithstanding that, I'm fairly firmly in
> the revert to default camp - I think on balance it conforms to the
> principle of least surprise.

I agree w/ Andrew on this, revert-to-default *is* what's expected by
most users/admins/etc, at least that I know. If we want something to be
a differential against the running config then let's pull out whatever
can be changed during runtime and write a .sql script that can be called
from the backend (set via the .conf) upon start and SIGHUP.

I think there'd be a great deal more understanding of how things work if
we then tell people that if they want to change things, change the .sql
and then run it, or run those commands themselves by hand; while the
.conf contains only those things that require a postmaster full restart
to be changed.

Just my 2c.

Thanks,

Stephen

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

> Not in any conf I have ever seen. If I comment out a parameter
> I expect that the parameter will either be disabled or set to the
> default depending on the parameter.

Or throw an error. I'm not sure what the big deal is with defaults -
everyone should be tuning their conf files intially anyway, the
defaults are just there to get you started. If you need a history,
put postgresql.conf into your local revisioning system, starting
with the supplied one (the "default") before you make any changes.

If everything is uncommented, it all becomes clear exactly what
will happen on reload.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200508250958
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkMNzrsACgkQvJuQZxSWSsgbPgCgqTEOjdxhJ1TCA/Fnl9UGFo/C
6lwAoOc5HGvR1kciqOSbZMaghUakmCpy
=+3h5
-----END PGP SIGNATURE-----

On Thu, Aug 25, 2005 at 02:09:10AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > On Wed, Aug 24, 2005 at 10:03:28PM -0700, Ron Mayer wrote:
> >> The most unambiguous behavior would be to not have
> >> commented out values in the config file at all.
>
> > That only makes sense if you also remove the concept of default values;
> > something I don't think we want to do.
>
> Well, the hardwired default values are really only there to ensure
> sanity if the config file fails to provide values. We already have to
> make sure that the hardwired defaults match what it says in
> postgresql.conf.sample, if only for documentation reasons. So I'm
> not seeing a strong argument here.

So then what happens if someone accidentally deletes something from the
config file? Or in-advertently comments it out?

IMHO, the best way to 'fix' this in the short term is to put a big
warning/notice in the config file letting people know what happens when
a setting is commented out/missing. In the long term we should go
through the same process for reading config settings on a reload as we
do on startup (with the obvious exception of startup-only parameters).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461

Tom Lane wrote:
> Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> > The most unambiguous behavior would be to not have
> > commented out values in the config file at all.
>
> Yeah, Robert Treat suggested that upthread, and I think it's been pushed
> by others too.
>
> The only argument I can see against it is that it'll take longer for the
> system to process such a file; but do we really care about a few more
> microseconds to respond to SIGHUP?
>
> This does not address the problem that changing PGC_POSTMASTER values in
> the file won't do anything without a postmaster restart. Greg Stark's
> suggestion of marking each PGC_POSTMASTER variable with a warning
> comment in postgresql.conf seems reasonable to me, though.

We should issue a warning in the server logs if someone tries to modify
a postmastger-only value on reload. Added to TODO:

o Issue a warning if a change-on-restart-only postgresql.conf value
is modified and the server config files are reloaded
o Mark change-on-restart-only values in postgresql.conf

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073