I failed to document the lock acquired on tables that reference the
partitioned table that we're detaching a partition from. This patch
(proposed for backpatch to 12, where that feature was added) fixes that
problem.
Noticed the omission a week ago while working out some details of
concurrent detach.
--
Álvaro Herrera 39°49'30"S 73°17'W
"It takes less than 2 seconds to get to 78% complete; that's a good sign.
A few seconds later it's at 90%, but it seems to have stuck there. Did
somebody make percentages logarithmic while I wasn't looking?"
http://smylers.hates-software.com/2005/09/08/1995c749.html
>From 98c0fe1d22333ea4ec27256f9c4dda98b1166b65 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvhe...@alvh.no-ip.org>
Date: Thu, 25 Mar 2021 14:53:21 -0300
Subject: [PATCH] Document lock obtained during partition detach
We acquire a SHARE lock all table that reference the partitioned table
that we're detaching a partition from, but failed to document this fact.
My oversight in commit f56f8f8da6af. Repair. Backpatch to 12.
---
doc/src/sgml/ref/alter_table.sgml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 0bd0c1a503..cd56d6a17e 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -962,6 +962,8 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
ties to the table from which it was detached. Any indexes that were
attached to the target table's indexes are detached. Any triggers that
were created as clones of those in the target table are removed.
+ <literal>SHARE</literal> lock is obtained on any tables that reference
+ this partitioned table in foreign key constraints.
</para>
</listitem>
</varlistentry>
--
2.20.1
