From 6cca1e1b7f2945db63863e236ca62a1d6291d493 Mon Sep 17 00:00:00 2001 From: Amit Langote Date: Fri, 27 Mar 2026 16:12:23 +0900 Subject: [PATCH v1] 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 Subplans Removed property in the - EXPLAIN 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 EXPLAIN - output and not the ones referred to by the - Subplans Removed property. + EXPLAIN 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. -- 2.47.3