Greetings,
* Laurenz Albe (laurenz.albe@cybertec.at) wrote:
> On Mon, 2020-01-13 at 13:56 -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.
>
> Right.
> But increasing the difficulty of restoring a version x pg_dump with
> version x + 1 is still not a thing we should lightly do.
I've never heard that and I don't agree with it being a justification
for blocking sensible progress.
> Not that the docs currently say "it is recommended to use pg_dumpall
> from the newer version". They don't say "is is not supported".
It's recommended due to exactly the reasons presented and no one is
saying that such isn't supported- but we don't and aren't going to
guarantee that it's going to work. We absolutely know of cases where it
just won't work, today. If that's justification for saying it's not
supported, then fine, let's change the language to say that.
Thanks,
Stephen