TODO questions

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

-----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@turnstep.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@candle.pha.pa.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

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@candle.pha.pa.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@sss.pgh.pa.us> writes:

Bruce Momjian <pgman@candle.pha.pa.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@pervasive.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@pervasive.com
Pervasive Software http://pervasive.com 512-569-9461

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

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@candle.pha.pa.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@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

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@pervasive.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@pervasive.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@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

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Wednesday, August 24, 2005 3:40 PM
To: Robert Treat
Cc: pgsql-hackers@postgresql.org; Jim Nasby; Greg Stark; Tom Lane
Subject: Re: [HACKERS] TODO questions

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.

Which is why I think it would be best to get as close as we can to the configuration that you'd get during a restart and warn about everything else. So, for example, if you're runing with a non-default shared_buffers and you comment shared_buffers out and do a reload, you should get a warning that shared_buffers has changed from xxx -> yyy but that change won't take effect until the server is restarted. That way there's absolutely no confusion.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com 512-569-9461

Tom Lane <tgl@sss.pgh.pa.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@pervasive.com
Pervasive Software http://pervasive.com 512-569-9461

Ron Mayer <rm_pg@cheapcomplexdevices.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@pervasive.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