]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Doc: fix stale text about partition locking with cached plans
authorAmit Langote <amitlan@postgresql.org>
Mon, 30 Mar 2026 01:29:21 +0000 (10:29 +0900)
committerAmit Langote <amitlan@postgresql.org>
Mon, 30 Mar 2026 01:29:21 +0000 (10:29 +0900)
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

index 8421ecace1b625b9f864991a4af16ee2c4373983..bd8cb461cba4f8005c36e25fa9af8a66be50f626 100644 (file)
@@ -5416,13 +5416,9 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= 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>