Greetings, * Laurenz Albe (laurenz.a...@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
signature.asc
Description: PGP signature
