On 2020-Aug-03, Alvaro Herrera wrote:
> Why two transactions? The reason is that in order for this to work, we
> make a catalog change (mark it detached), and commit so that all
> concurrent transactions can see the change. A second transaction waits
> for anybody who holds any lock on the partitioned table and grabs Access
> Exclusive on the partition (which now no one cares about, if they're
> looking at the partitioned table), where the DDL action on the partition
> can be completed.
I forgot to mention. If for whatever reason the second transaction
fails, (say the user aborts it or there is a crash), then the partition
is still marked as detached, so no queries would see it; but all the
ancillary catalog data remains. Just like when CREATE INDEX
CONCURRENTLY fails, you keep an invalid index that must be dropped; in
this case, the changes to do are much more extensive, so manual action
is out of the question. So there's another DDL command to be invoked,
ALTER TABLE parent DETACH PARTITION part FINALIZE;
which will complete the detach action.
If we had UNDO then perhaps it would be possible to register an action
so that the detach is completed automatically. But for now this seems
sufficient.
Another aspect worth mentioning is constraints. In the patch, I create
a CHECK constraint to stand for the partition constraint that's going to
logically disappear. This was mentioned as a potential problem in one
of Robert's emails (I didn't actually verify that this is a problem).
However, a funny thing is that if a constraint already exists, you get a
dupe, so after a few rounds of attach/detach you can see them pile up.
I'll have to fix this at some point. But also, I need to think about
whether foreign keys have similar problems, since they are also used by
the optimizer.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
