From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: propagating replica identity to partitions |
Date: | 2019-02-04 23:53:59 |
Message-ID: | 201902042353.r3aqj2cx4hvz@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Actually, index-based replica identities failed in pg_dump: we first
create the index ONLY on the partitioned table (marking it as invalid),
so when we immediately do the ALTER TABLE/REPLICA IDENTITY, it rejects
the invalid index. If we change the code to allow invalid indexes on
partitioned tables to become replica identities, we hit the problem that
the index didn't exist when processing the partition list. In order to
fix that, I added a flag so that partitions are allowed not to have the
index, in hopes that the missing index are created in subsequent
commands; those indexes should become valid & identity afterwards.
There's a small emerging problem, which is that if you have an invalid
index marked as replica identity, you cannot create any more partitions;
the reason is that we want to propagate the replica identity to the
partition, but the index is not there (since invalid indexes are not
propagated). I don't think this case is worth supporting; it can be
fixed but requires some work[1].
New patch attached.
[1] In DefineRelation, we obtain the list of indexes to clone by
RelationGetIndexList, which ignores invalid indexes. In order to
implement this we'd need to include invalid indexes in that list
(possibly by just not using RelationGetIndexList.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
v3-0001-index_get_partition.patch | text/x-diff | 4.3 KB |
v3-0002-Propagate-replica-identity-to-partitions.patch | text/x-diff | 23.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-02-05 00:15:06 | Re: Tighten up a few overly lax regexes in pg_dump's tap tests |
Previous Message | David Rowley | 2019-02-04 23:14:09 | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |