On Fri, Mar 27, 2026 at 4:15 PM Amit Langote <[email protected]> wrote: > On Fri, Mar 27, 2026 at 4:09 PM Amit Langote <[email protected]> wrote: > > Hi David, > > > > On Wed, Apr 2, 2025 at 10:03 AM David Rowley <[email protected]> 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 <[email protected]> > > > 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
