Re: our checks for read-only queries are not great

On Mon, Jan 27, 2020 at 02:26:42PM -0500, Stephen Frost wrote:
> Greetings,
> 
> * Bruce Momjian (bruce@momjian.us) wrote:
> > On Mon, Jan 13, 2020 at 01:56:30PM -0500, Stephen Frost wrote:
> > > > 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.
> > > 
> > > pg_dump already specifically has understanding of how to deal with old
> > > options in other things when constructing a dump for a given version-
> > > and we already have issues that a dump taken with pg_dump X has a good
> > > chance of now being able to be restoreding into a PG X+1, that's why
> > > it's recommended to use the pg_dump for the version of PG you're
> > > intending to restore into, so I don't particularly agree with any of the
> > > arguments presented above.
> > 
> > One issue is that system table GUC settings (e.g., per-database,
> > per-user) cannot include postgresql.conf-only settings, like
> > max_wal_size, so system tables GUC settings are less likely to be
> > renamed than postgresql.conf.auto settings.  FYI, we are more inclined
> > to allow postgresql.conf-only changes than others because there is less
> > impact on applications.
> 
> I'm a bit unclear about what's being suggested here.  When you are
> talking about 'applications', are you referring specifically to pg_dump
> and pg_restore, or are you talking about regular user applications?

Sorry for the late reply.  I meant all applications.

> If you're referring to pg_dump/restore, then what I'm understanding from
> your comments is that if we made pg_dump/restore aware of ALTER SYSTEM
> and were made to support it that we would then be less inclined to
> change the names of postgresql.conf-only settings because, if we do so,
> we have to update pg_dump/restore.
> 
> I can see some argument in that direction but my initial reaction is
> that I don't feel like the bar would really be moved very far, and, if
> we came up with some mapping from one to the other for those, I actually
> think it'd be really helpful downstream for packagers and such who
> routinely are dealing with updating from an older postgresql.conf file
> to a newer one when an upgrade is done.

I should have given more examples.  Changing GUC variables like
search_path or work_mem, which can be set in per-database, per-user, and
per-session contexts, is more disruptive than changing GUCs that can
only can be set in postgresql.conf, like max_wal_size.  My point is that
all GUC changes don't have the same level of disruption.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +