Over in [1], there was some uncertainty about whether locking an unrelated partition was expected behaviour or not for the particular use-case which used a generic plan to scan a partitioned table and all of the partitions.
I noticed that we don't mention this in the docs and though that perhaps we should. I thought a good place might be in [2] at the end of the following paragraph:
"During initialization of the query plan. Partition pruning can be performed here for parameter values which are known during the initialization phase of execution. Partitions which are pruned during this stage will not show up in the query's EXPLAIN or EXPLAIN ANALYZE. It is possible to determine the number of partitions which were removed during this phase by observing the “Subplans Removed” property in the EXPLAIN output."
Perhaps adding something like "Because all relations which are part of the plan are locked at the beginning of execution, any partitions pruned at this stage are already locked and will remain so until the end of the transaction.".
or:
"It's important to note that any partitions removed by the partition pruning done at this stage are still locked at the beginning of execution".
I prefer this.
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" .
