Re: Segfault when restoring -Fd dump on current HEAD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Segfault when restoring -Fd dump on current HEAD
Date
Msg-id 13742.1551286963@sss.pgh.pa.us
Whole thread Raw
In response to Re: Segfault when restoring -Fd dump on current HEAD  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Segfault when restoring -Fd dump on current HEAD  (Dmitry Dolgov <9erthalion6@gmail.com>)
Re: Segfault when restoring -Fd dump on current HEAD  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-27, Dmitry Dolgov wrote:
>> But I hope there are no objections if I'll then submit the original
>> changes with more consistent null handling separately to make decision
>> about them more consciously.

> I think we should save such a patch for whenever we next update the
> archive version number, which could take a couple of years given past
> history.  I'm inclined to add a comment near K_VERS_SELF to remind
> whoever next patches it.

+1.  This isn't an unreasonable cleanup idea, but being only a cleanup
idea, it doesn't seem worth creating compatibility issues for.  Let's
wait till there is some more-pressing reason to change the archive format,
and then fix this in the same release cycle.

I'd also note that given what we've seen so far, there are going to be
some slow-to-flush-out null pointer dereferencing bugs from this.
I'm not really eager to introduce that towards the tail end of a devel
cycle.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Index INCLUDE vs. Bitmap Index Scan
Next
From: Dmitry Dolgov
Date:
Subject: Re: Segfault when restoring -Fd dump on current HEAD