postgres.git / summary / log / commit / refs
commit c57d8178eb06ec001b6538c3bb985e079b6d329b
Author: Amit Langote <amitlan@postgresql.org>
Date: Mon Mar 30 01:29:21 2026 +0000
First released in: 18.4
Doc: fix stale text about partition locking with cached plans
Commit 121d774caea added text to master describing pruning-aware
locking behavior introduced by 525392d57. That behavior was
reverted in May 2025, making the text incorrect. Replace it with
the text used in back branches, which correctly describes current
behavior: pruned partitions are still locked at the beginning of
execution.
Discussion: https://postgr.es/m/CA+HiwqFT0fPPoYBr0iUFWNB-Og7bEXB9hB=6ogk_qD9=OM8Vbw@mail.gmail.com
doc/src/sgml/ddl.sgml | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 8421ecace1b..bd8cb461cba 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -5416,13 +5416,9 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
It is possible to determine the number of partitions which were
removed during this phase by observing the
<quote>Subplans Removed</quote> property in the
- <command>EXPLAIN</command> output. The query planner obtains locks for
- all partitions which are part of the plan. However, when the executor
- uses a cached plan, locks are only obtained on the partitions which
- remain after partition pruning done during the initialization phase of
- execution, i.e., the ones shown in the <command>EXPLAIN</command>
- output and not the ones referred to by the
- <quote>Subplans Removed</quote> property.
+ <command>EXPLAIN</command> output. It's important to note that any
+ partitions removed by the partition pruning done at this stage are
+ still locked at the beginning of execution.
</para>
</listitem>
[parent: 1ad7191f7e92]