pgsql: Doc: add information about partition locking
Doc: add information about partition locking
The documentation around locking of partitions for the executor startup
phase of run-time partition pruning wasn't clear about which partitions
were being locked. Fix that.
Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: /messages/by-id/CAApHDvp738G75HfkKcfXaf3a8s=6mmtOLh46tMD0D2hAo1UCzA@mail.gmail.com
Backpatch-through: 13
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/121d774caea4c93c8b36fb20a17ef774e60894d6
Modified Files
--------------
doc/src/sgml/ddl.sgml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
Hi David,
On Wed, Apr 2, 2025 at 10:03 AM David Rowley <drowley@postgresql.org> wrote:
Doc: add information about partition locking
The documentation around locking of partitions for the executor startup
phase of run-time partition pruning wasn't clear about which partitions
were being locked. Fix that.Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: /messages/by-id/CAApHDvp738G75HfkKcfXaf3a8s=6mmtOLh46tMD0D2hAo1UCzA@mail.gmail.com
Backpatch-through: 13Branch
------
masterDetails
-------
https://git.postgresql.org/pg/commitdiff/121d774caea4c93c8b36fb20a17ef774e60894d6
- <command>EXPLAIN</command> output.
+ <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.
</para>
</listitem>This text was correct when committed, but became incorrect after I
reverted 525392d57 in May 2025. Sorry for not catching it sooner.
I think we should change the text in both master and REL_18_STABLE to
match what you added in the older branches. I can change it back to
this when we get pruning-aware locking again.
--
Thanks, Amit Langote
On Fri, Mar 27, 2026 at 4:09 PM Amit Langote <amitlangote09@gmail.com> wrote:
Hi David,
On Wed, Apr 2, 2025 at 10:03 AM David Rowley <drowley@postgresql.org> wrote:
Doc: add information about partition locking
The documentation around locking of partitions for the executor startup
phase of run-time partition pruning wasn't clear about which partitions
were being locked. Fix that.Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: /messages/by-id/CAApHDvp738G75HfkKcfXaf3a8s=6mmtOLh46tMD0D2hAo1UCzA@mail.gmail.com
Backpatch-through: 13Branch
------
masterDetails
-------
https://git.postgresql.org/pg/commitdiff/121d774caea4c93c8b36fb20a17ef774e60894d6- <command>EXPLAIN</command> output. + <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. </para> </listitem>This text was correct when committed, but became incorrect after I
reverted 525392d57 in May 2025. Sorry for not catching it sooner.I think we should change the text in both master and REL_18_STABLE to
match what you added in the older branches. I can change it back to
this when we get pruning-aware locking again.
Will apply the attached.
--
Thanks, Amit Langote
Attachments:
v1-0001-Doc-fix-stale-text-about-partition-locking-with-c.patchapplication/octet-stream; name=v1-0001-Doc-fix-stale-text-about-partition-locking-with-c.patchDownload+3-8
On Fri, Mar 27, 2026 at 4:15 PM Amit Langote <amitlangote09@gmail.com> wrote:
On Fri, Mar 27, 2026 at 4:09 PM Amit Langote <amitlangote09@gmail.com> wrote:
Hi David,
On Wed, Apr 2, 2025 at 10:03 AM David Rowley <drowley@postgresql.org> wrote:
Doc: add information about partition locking
The documentation around locking of partitions for the executor startup
phase of run-time partition pruning wasn't clear about which partitions
were being locked. Fix that.Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: /messages/by-id/CAApHDvp738G75HfkKcfXaf3a8s=6mmtOLh46tMD0D2hAo1UCzA@mail.gmail.com
Backpatch-through: 13Branch
------
masterDetails
-------
https://git.postgresql.org/pg/commitdiff/121d774caea4c93c8b36fb20a17ef774e60894d6- <command>EXPLAIN</command> output. + <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. </para> </listitem>This text was correct when committed, but became incorrect after I
reverted 525392d57 in May 2025. Sorry for not catching it sooner.I think we should change the text in both master and REL_18_STABLE to
match what you added in the older branches. I can change it back to
this when we get pruning-aware locking again.Will apply the attached.
Pushed.
--
Thanks, Amit Langote