From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | pg_dump INDEX ATTACH versus --clean option |
Date: | 2021-01-12 19:48:49 |
Message-ID: | 1228964.1610480929@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I noticed that pg_dump --clean does not work with partitioned
indexes. Given for instance
create schema s1;
create table s1.at1 (f1 int, f2 int, primary key(f1,f2)) partition by list(f1);
create table s1.at11 partition of s1.at1 for values in(11);
create table s1.at12 partition of s1.at1 for values in(12);
then "pg_dump -n s1 -c mydb >mydb.dump" will emit
ALTER TABLE ONLY s1.at12 DROP CONSTRAINT at12_pkey;
ALTER TABLE ONLY s1.at11 DROP CONSTRAINT at11_pkey;
ALTER TABLE ONLY s1.at1 DROP CONSTRAINT at1_pkey;
DROP TABLE s1.at12;
DROP TABLE s1.at11;
DROP TABLE s1.at1;
DROP SCHEMA s1;
... then create the objects ...
which naturally results in
psql:mydb.dump:19: ERROR: cannot drop inherited constraint "at12_pkey" of relation "at12"
psql:mydb.dump:20: ERROR: cannot drop inherited constraint "at11_pkey" of relation "at11"
ALTER TABLE
DROP TABLE
DROP TABLE
DROP TABLE
DROP SCHEMA
That's not really okay, since it'd break a single-transaction
restore.
Since there's no ALTER INDEX DETACH PARTITION, it's not entirely
clear what to do about this. We could possibly not emit any
dropStmt for partition child indexes, but that seems very likely
to cause problems for partial-restore scenarios.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-01-12 19:51:39 | Re: [DOC] Document concurrent index builds waiting on each other |
Previous Message | Andres Freund | 2021-01-12 19:34:31 | Re: Key management with tests |