From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
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> |
Subject: | Re: pg_dump is broken for partition tablespaces |
Date: | 2019-03-06 16:17:44 |
Message-ID: | 20190306161744.22jdkg37fyi2zyke@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-03-06 19:45:06 +1300, David Rowley wrote:
> Over on [1] Andres pointed out that the pg_dump support for the new to
> PG12 tablespace inheritance feature is broken. This is the feature
> added in ca4103025dfe26 to allow a partitioned table to have a
> tablespace that acts as the default tablespace for newly attached
> partitions. The idea being that you can periodically change the
> default tablespace for new partitions to a tablespace that sits on a
> disk partition with more free space without affecting the default
> tablespace for normal non-partitioned tables. Anyway...
I'm also concerned that the the current catalog representation isn't
right. As I said:
> I also find it far from clear that:
> <listitem>
> <para>
> The <replaceable class="parameter">tablespace_name</replaceable> is the name
> of the tablespace in which the new table is to be created.
> If not specified,
> <xref linkend="guc-default-tablespace"/> is consulted, or
> <xref linkend="guc-temp-tablespaces"/> if the table is temporary. For
> partitioned tables, since no storage is required for the table itself,
> the tablespace specified here only serves to mark the default tablespace
> for any newly created partitions when no other tablespace is explicitly
> specified.
> </para>
> </listitem>
> is handled correctly. The above says that the *specified* tablespaces -
> which seems to exclude the default tablespace - is what's going to
> determine what partitions use as their default tablespace. But in fact
> that's not true, the partitioned table's pg_class.retablespace is set to
> what default_tablespaces was at the time of the creation.
I still think the feature as is doesn't seem to have very well defined
behaviour.
> If we instead did:
>
> CREATE TABLE public.listp1 (a integer
> );
>
> ALTER TABLE public.list1 ATTACH PARTITION public.listp FOR VALUES IN (1);
Isn't that a bit more expensive, because now the table needs to be
scanned for maching the value? That's probably neglegible though, given
it'd probably always empty.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-06 16:30:59 | Re: patch to allow disable of WAL recycling |
Previous Message | Chapman Flack | 2019-03-06 16:16:11 | Re: PostgreSQL vs SQL/XML Standards |