Re: Add mention in docs about locking all partitions for generic plans

David Rowley <dgrowleyml(at)gmail(dot)com> 于2025年3月24日周一 16:50写道：

> On Mon, 24 Mar 2025 at 19:50, Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> >
> > David Rowley <dgrowleyml(at)gmail(dot)com> 于2025年3月24日周一 05:28写道：
> >> This is no longer true in master, so if we do something here it's only
> >> v17 and earlier.
> >
> > In the case of [1], we still have AccessShareLock on entity_2, even
> though it is pruned during initial partition pruning.
> > This seems to contradict what you said. "This is no longer true in
> master" .
>
> For that particular case, planning occurs each time prior to execution
> and it's the planner that takes the lock, not the executor. If you
> want to not plan each time then you could modify that case to use a
> plpgsql function instead of sql and then ensure you're using a cached
> plan with "set plan_cache_mode = force_generic_plan;" (apparently we
> don't cache plans for non-inlined SQL functions). I disagree that this
> makes the proposed sentence untrue. 525392d57 did change the order of
> operations here so that the partitions in the Append/MergeAppend are
> locked after run-time pruning occurs at executor startup.
>

Thanks for the explanation.

>
> Maybe I was wrong about writing nothing in master's docs. It might
> still be important to detail this. I don't know the best way to phrase
> that, but maybe something along the lines of: "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.".
>
> Any opinions?
>

The above sentence looks good to me.

--
Thanks,
Tender Wang