Re: pg_dump is broken for partition tablespaces

On 2019/04/23 20:03, David Rowley wrote:
> On Tue, 23 Apr 2019 at 18:18, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.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.

Not completely though, because...

> 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.

This is the case I was talking about, which I agree is very rare.  Sorry
for being unclear.

I think your proposed patch is fine and I don't want to argue that the way
things are now has some very sound basis.

Also, as you and Alvaro have found, the existing arrangement makes pg_dump
emit partitions in a way that's not super helpful (insert/copy failing
unintuitively), but it's not totally broken either.  That said, I don't
mean to oppose back-patching any fix you think is appropriate.

Thank you for working on this.

Regards,
Amit