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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
