Doc: Clarify lock levels taken during ATTACH PARTITION

It wasn't all that clear which lock levels, if any, would be held on the
DEFAULT partition during an ATTACH PARTITION operation.

Also, clarify which locks will be taken if the DEFAULT partition or the
table being attached are themselves partitioned tables.

Here I'm only backpatching to v12 as before then we obtained an ACCESS
EXCLUSIVE lock on the partitioned table.  It seems much less relevant to
mention which locks are taken on other tables when the partitioned table
itself is locked with an ACCESS EXCLUSIVE lock.

Author: Matthias van de Meent, David Rowley
Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com
Backpatch-through: 12
This commit is contained in:
David Rowley 2021-07-28 15:01:40 +12:00
parent b8f91d7f92
commit aa1e9211ec
2 changed files with 36 additions and 5 deletions

View File

@ -3968,6 +3968,11 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
</programlisting>
</para>
<para>
The <command>ATTACH PARTITION</command> command requires taking a
<literal>SHARE UPDATE EXCLUSIVE</literal> lock on the partitioned table.
</para>
<para>
Before running the <command>ATTACH PARTITION</command> command, it is
recommended to create a <literal>CHECK</literal> constraint on the table to
@ -3976,10 +3981,27 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
which is otherwise needed to validate the implicit
partition constraint. Without the <literal>CHECK</literal> constraint,
the table will be scanned to validate the partition constraint while
holding both an <literal>ACCESS EXCLUSIVE</literal> lock on that partition
and a <literal>SHARE UPDATE EXCLUSIVE</literal> lock on the parent table.
holding an <literal>ACCESS EXCLUSIVE</literal> lock on that partition.
It is recommended to drop the now-redundant <literal>CHECK</literal>
constraint after <command>ATTACH PARTITION</command> is finished.
constraint after the <command>ATTACH PARTITION</command> is complete. If
the table being attached is itself a partitioned table then each of its
sub-partitions will be recursively locked and scanned until either a
suitable <literal>CHECK</literal> constraint is encountered or the leaf
partitions are reached.
</para>
<para>
Similarly, if the partitioned table has a <literal>DEFAULT</literal>
partition, it is recommended to create a <literal>CHECK</literal>
constraint which excludes the to-be-attached partition's constraint. If
this is not done then the <literal>DEFAULT</literal> partition will be
scanned to verify that it contains no records which should be located in
the partition being attached. This operation will be performed whilst
holding an <literal>ACCESS EXCLUSIVE</literal> lock on the <literal>
DEFAULT</literal> partition. If the <literal>DEFAULT</literal> partition
is itself a partitioned table then each of its partitions will be
recursively checked in the same way as the table being attached, as
mentioned above.
</para>
<para>

View File

@ -934,8 +934,17 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
<para>
Attaching a partition acquires a
<literal>SHARE UPDATE EXCLUSIVE</literal> lock on the parent table,
in addition to <literal>ACCESS EXCLUSIVE</literal> locks on the table
to be attached and on the default partition (if any).
in addition to the <literal>ACCESS EXCLUSIVE</literal> locks on the table
being attached and on the default partition (if any).
</para>
<para>
Further locks must also be held on all sub-partitions if the table being
attached is itself a partitioned table. Likewise if the default
partition is itself a partitioned table. The locking of the
sub-partitions can be avoided by adding a <literal>CHECK</literal>
constraint as described in
<xref linkend="ddl-partitioning-declarative-maintenance"/>.
</para>
</listitem>
</varlistentry>