From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: our checks for read-only queries are not great |
Date: | 2020-01-27 19:26:42 |
Message-ID: | 20200127192642.GC3195@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Bruce Momjian (bruce(at)momjian(dot)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?
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.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-01-27 19:44:13 | Re: [Proposal] Global temporary tables |
Previous Message | Robert Haas | 2020-01-27 19:02:26 | Re: JIT performance bug/regression & JIT EXPLAIN |