Re: pg_dump is broken for partition tablespaces

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: pg_dump is broken for partition tablespaces
Date: 2019-03-06 07:19:00
Message-ID: 20190306071900.GI30982@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 06, 2019 at 07:45:06PM +1300, David Rowley wrote:
> Partitioned indexes have this similar inherit tablespace from parent
> feature, so ca4103025dfe26 was intended to align the behaviour of the
> two. Partitioned indexes happen not to suffer from the same issue as
> the indexes are attached after their creation similar to what I
> propose above.
>
> Can anyone see any fundamental reason that we should not create a
> partitioned table by doing CREATE TABLE followed by ATTACH PARTITION?
> If not, I'll write a patch that fixes it that way.

The part for partitioned indexes is already battle-proven, so if the
part for partitioned tables can be consolidated the same way that
would be really nice.

> As far as I can see, the biggest fundamental difference with doing
> things this way will be that the column order of partitions will be
> preserved, where before it would inherit the order of the partitioned
> table. I'm a little unsure if doing this column reordering was an
> intended side-effect or not.

I don't see any direct issues with that to be honest thinking about
it..
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-03-06 08:27:30 Re: BUG #15668: Server crash in transformPartitionRangeBounds
Previous Message Rushabh Lathia 2019-03-06 07:13:17 ECPG regression with DECLARE STATEMENT support