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
