Обсуждение: 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: https://postgr.es/m/CAApHDvp738G75HfkKcfXaf3a8s%3D6mmtOLh46tMD0D2hAo1UCzA%40mail.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: https://postgr.es/m/CAApHDvp738G75HfkKcfXaf3a8s%3D6mmtOLh46tMD0D2hAo1UCzA%40mail.gmail.com > Backpatch-through: 13 > > Branch > ------ > master > > Details > ------- > 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: https://postgr.es/m/CAApHDvp738G75HfkKcfXaf3a8s%3D6mmtOLh46tMD0D2hAo1UCzA%40mail.gmail.com > > Backpatch-through: 13 > > > > Branch > > ------ > > master > > > > Details > > ------- > > 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
Вложения
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: https://postgr.es/m/CAApHDvp738G75HfkKcfXaf3a8s%3D6mmtOLh46tMD0D2hAo1UCzA%40mail.gmail.com > > > Backpatch-through: 13 > > > > > > Branch > > > ------ > > > master > > > > > > Details > > > ------- > > > 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