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

From Dmitry Dolgov
Subject Re: Segfault when restoring -Fd dump on current HEAD
Date
Msg-id CA+q6zcWUBA9O3LTRLtUWxfymzmcJ0hMbe=Tw23Ox2ZuW6ia+=Q@mail.gmail.com
Whole thread Raw
In response to Re: Segfault when restoring -Fd dump on current HEAD  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
> On Tue, Feb 26, 2019 at 9:13 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > On Tue, Feb 26, 2019 at 6:38 AM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > Works for me.  With a quick read of the code, it seems to me that it
> > is possible to keep compatibility while keeping the simplifications
> > around ArchiveEntry()'s refactoring.
>
> Yes, it should be rather simple, we can e.g. return to the old less consistent
> NULL handling approach something (like in the attached patch), or replace a NULL
> value with an empty string in WriteToc. Give me a moment, I'll check it out. At
> the same time I would suggest to keep replace_line_endings -> sanitize_line,
> since it doesn't break compatibility.

Ok, unfortunately, I don't see any other ways, so the patch from the previous
email is probably the best option (we could also check NULLs in WriteToc, but
it means the same kind of inconsistency, and in this case I guess it's better
to keep NULL handling as it was before).

But I hope it still makes sense to consider more consisten approach here, maybe
with the next dump version bump, if it's going to happen in the foreseeable
future.


pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: NOT IN subquery optimization
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum