| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_dump is broken for partition tablespaces |
| Date: | 2019-04-23 11:03:16 |
| Message-ID: | CAKJS1f9k0Jnaf3mEZZrTN8SfANcOprN6YmF+U3TZMFBSYU1QuA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 23 Apr 2019 at 18:18, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> If partitions needed a
> map in the old database, this patch means that they will *continue* to
> need it in the new database.
That's incorrect. My point was about dropped columns being removed
after a dump / reload. Only binary upgrade mode preserves
pg_attribute entries for dropped columns. Normal mode does not, so the
maps won't be needed after the reload if they were previously only
needed due to dropped columns. This is the case both with and without
the pg_dump changes I proposed. The case the patch does change is if
the columns were actually out of order, which I saw as an unlikely
thing to happen in the real world.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2019-04-23 11:04:13 | Re: New vacuum option to do only freezing |
| Previous Message | Kyotaro HORIGUCHI | 2019-04-23 10:20:33 | Re: Regression test PANICs with master-standby setup on same machine |