| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | 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-25 16:20:14 |
| Message-ID: | 31551.1551111614@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> What's crashing for me is restoring the (12dev) dumpfile using v11 psql:
Yeah, I can reproduce that here, using either -Fc or -Fd format dumps.
The immediate problem in your example is that the "defn" field of a
TABLE DATA entry is now null where it used to be an empty string.
Poking at related examples suggests that other fields have suffered
the same fate.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hubert depesz lubaczewski | 2019-02-25 16:20:54 | Re: Segfault when restoring -Fd dump on current HEAD |
| Previous Message | Corey Huinker | 2019-02-25 16:17:05 | Re: some ri_triggers.c cleanup |