database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-22 17:42:17 +03:00
Code Activity

Doc: Clarify lock levels taken during ATTACH PARTITION

Browse Source 
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:02:37 +12:00
parent 7b7fbe1e8b
commit 8709228775
2 changed files with 36 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/src/sgml/ref/alter_table.sgml
View File

@@ -976,8 +976,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>