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

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.

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?

> [1] https://postgr.es/m/01020195b987abd3-a008b77d-8c63-4931-80a4-be36a351c8b2-000000@eu-west-1.amazonses.com

David