Re: Segfault when restoring -Fd dump on current HEAD

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Feb 25, 2019 at 11:20:14AM -0500, Tom Lane wrote:
>> It appears to me that f831d4acc required a good deal more adult
>> supervision than it actually got. That was alleged to be a small
>> notational refactoring, not a redefinition of what gets put into
>> dump files.

> How much consistent do we need to be for custom dump archives
> regarding backward and upward-compatibility?

Well, if we didn't want to fix this, a reasonable way to go about
it would be to bump the archive version number in pg_dump output,
so that old versions would issue a useful complaint instead of crashing.
However, I repeat that this patch was sold as a notational improvement,
not something that was going to break format compatibility. I think if
anyone had mentioned the latter, there would have been push-back against
its being committed at all. I am providing such push-back right now,
because I don't think we should break file compatibility for this.

Also, I'm now realizing that 4dbe19690 was probably not fixing an
aboriginal bug, but something that this patch introduced, because
we'd likely have noticed it before if the owner field could have
been a null pointer all along. How much do you want to bet on
whether there are other such bugs now, that we haven't yet tripped
over?

I think this patch needs to be worked over so that what it writes
is exactly what was written before. If the author is unwilling
to do that PDQ, it should be reverted.

regards, tom lane