Re: Segfault when restoring -Fd dump on current HEAD

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: Segfault when restoring -Fd dump on current HEAD
Дата
Msg-id CA+q6zcWUBA9O3LTRLtUWxfymzmcJ0hMbe=Tw23Ox2ZuW6ia+=Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Segfault when restoring -Fd dump on current HEAD  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: NOT IN subquery optimization
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum