| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, depesz(at)depesz(dot)com, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Segfault when restoring -Fd dump on current HEAD |
| Date: | 2019-02-26 04:37:18 |
| Message-ID: | 20190226043718.GB27822@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2019-02-26 04:38:41 | Re: Remove Deprecated Exclusive Backup Mode |
| Previous Message | Haribabu Kommi | 2019-02-26 04:34:54 | Re: [HACKERS] Block level parallel vacuum |