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

From Michael Paquier
Subject Re: Segfault when restoring -Fd dump on current HEAD
Date
Msg-id 20190226043718.GB27822@paquier.xyz
Whole thread Raw
In response to Re: Segfault when restoring -Fd dump on current HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Segfault when restoring -Fd dump on current HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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?  For dumps, we give no
guarantee that a dump taken with pg_dump on version N will be
compatible with a backend at version (N+1), so there is a effort for
backward compatibility, not really upward compatibility.

It seems to me that f831d4acc should have bumped at least
MAKE_ARCHIVE_VERSION as it changes the dump contents, still it seems
like a lot of for some refactoring?  FWIW, I have gone through the
commit's thread and I actually agree that instead of a mix of empty
strings and NULL, using only NULL is cleaner.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Mark Kirkwood
Date:
Subject: Re: Remove Deprecated Exclusive Backup Mode