On Fri, 2020-01-10 at 09:29 -0500, Tom Lane wrote:
> > ALTER SYSTEM is read only in my mind.
>
> I'm still having trouble with this conclusion. I think it can only
> be justified by a very narrow reading of "reflected in pg_dump"
> that relies on the specific factorization we've chosen for upgrade
> operations, ie that postgresql.conf mods have to be carried across
> by hand. But that's mostly historical baggage, rather than a sane
> basis for defining "read only". If somebody comes up with a patch
> that causes "pg_dumpall -g" to include ALTER SYSTEM SET commands for
> whatever is in postgresql.auto.conf (not an unreasonable idea BTW),
> will you then decide that ALTER SYSTEM SET is no longer read-only?
I think that having ALTER SYSTEM commands in pg_dumpall output
would be a problem. It would cause all kinds of problems whenever
parameters change. Thinking of the transition "checkpoint_segments"
-> "max_wal_size", you'd have to build some translation magic into pg_dump.
Besides, such a feature would make it harder to restore a dump taken
with version x into version x + n for n > 0.
> Or, perhaps, reject such a patch on the grounds that it breaks this
> arbitrary definition of read-only-ness?
I agree with Robert that such a patch should be rejected on other
grounds.
Concerning the topic of the thread, I personally have come to think
that changing GUCs is *not* writing to the database. But that is based
on the fact that you can change GUCs on streaming replication standbys,
and it may be surprising to a newcomer.
Perhaps it would be good to consider this question:
Do we call something "read-only" if it changes nothing, or do we call it
"read-only" if it is allowed on a streaming replication standby?
The first would be more correct, but the second may be more convenient.
Yours,
Laurenz Albe
