]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Doc: fix stale text about partition locking with cached plans
authorAmit Langote <amitlan@postgresql.org>
Fri, 27 Mar 2026 07:12:23 +0000 (16:12 +0900)
committerAmit Langote <amitlan@postgresql.org>
Mon, 30 Mar 2026 01:29:52 +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 49c98967d5012c74b996e5202191adeed5a59856..8813a09561b71439d5f270438b0c7d85c6f23cbc 100644 (file)
@@ -5085,13 +5085,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>