On Fri, Jan 10, 2020 at 9:30 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > 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? > Or, perhaps, reject such a patch on the grounds that it breaks this > arbitrary definition of read-only-ness?
I would vote to reject such a patch as a confused muddle. I mean, generally, the expectation right now is that if you move your data from the current cluster to a new one by pg_dump, pg_upgrade, or even by promoting a standby, you're responsible for making sure that postgresql.conf and postgresql.auto.conf get copied over separately. In the last case, the backup that created the standby will have copied the postgresql.conf from the master as it existed at that time, but propagating any subsequent changes is up to you. Now, if we now decide to shove ALTER SYSTEM SET commands into pg_dumpall output, then suddenly you're changing that rule, and it's not very clear what the new rule is. Now, our current approach is fairly arguable. Given that GUCs on databases, users, functions, etc. are stored in the catalogs and subject to backup, restore, replication, etc., one might well expect that global settings would be handled the same way. I tend to think that would be nicer, though it would require solving the problem of how to back out bad changes that make the database not start up. Regardless of what you or anybody thinks about that, though, it's not how it works today and would require some serious engineering if we wanted to make it happen. > As another example, do we need to consider that replacing pg_hba.conf > via pg_write_file should be allowed in a "read only" transaction? I don't really see what the problem with that is. It bothers me a lot more that CLUSTER can be run in a read-only transaction -- which actually changes stuff inside the database, even if not necessarily in a user-visible way -- than it does that somebody might be able to use the database to change something that isn't really part of the database anyway. And pg_hba.conf, like postgresql.conf, is largely treated as an input to the database rather than part of it. Somebody could create a user-defined function that launches a satellite into orbit and that is, I would argue, a write operation in the truest sense. You have changed the state of the world in a lasting way, and you cannot take it back. But, it's not writing to the database, so as far as read-only transactions are concerned, who cares? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
