Re: Per-database and per-user GUC settings

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I think it's desirable and fully intentional. How else would you override
> command-line args without restarting the server?

I say you wouldn't. If it's on the command line then it overrides
postgresql.conf for that run of the postmaster; full stop, no "if"s.
If you wanted it to be changeable within-run by postgresql.conf then you
should have edited postgresql.conf to start with.

As the implementation currently works, applying a setting via the
command line is entirely unsafe unless you then back it up with fixing
the value in postgresql.conf; otherwise an unrelated change to
postgresql.conf, perhaps much later, blows the command-line setting
out of the water. You might as well eliminate command-line settings
entirely, if they have to be accompanied by a matching change in
postgresql.conf in order to work reliably.

IMHO the only reason we haven't gotten squawks about this is that
(a) the majority of uses of command-line arguments are for options
that can't be changed after postmaster start anyway (-i, -p, -B, -N);
(b) since the factory-default postgresql.conf has all settings commented
out, it doesn't actually cause reversions to happen at SIGHUP.

If any significant number of people were actually being exposed to the
current behavior, we'd be getting complaints; lots of 'em. At the
moment it's only a corner case because of considerations (a) and (b),
so few people have had it happen to them.

> but in my mind, if you're using command-line arguments
> in permanent setups, you're not trying hard enough.

You're essentially saying that command-line arguments are only useful
for prototyping changes that you intend to make in postgresql.conf
immediately thereafter. Again, why have we got a command-line option
facility at all? Might as well make the change in postgresql.conf
to begin with, if that's the viewpoint.

regards, tom lane