On Fri, Jan 20, 2023 at 12:52 PM Amit Langote <amitlangote09@gmail.com> wrote:
> Alright, I'll try to get something out early next week. Thanks for
> all the pointers.
Sorry for the delay. Attached is what I've come up with so far.
I didn't actually go with calling the plancache on every lock taken on
a relation, that is, in ExecGetRangeTableRelation(). One thing about
doing it that way that I didn't quite like (or didn't see a clean
enough way to code) is the need to complicate the ExecInitNode()
traversal for handling the abrupt suspension of the ongoing setup of
the PlanState tree.
So, I decided to keep the current model of locking all the relations
that need to be locked before doing anything else in InitPlan(), much
as how AcquireExecutorLocks() does it. A new function called from
the top of InitPlan that I've called ExecLockRelationsIfNeeded() does
that locking after performing the initial pruning in the same manner
as the earlier patch did. That does mean that I needed to keep all
the adjustments of the pruning code that are required for such
out-of-ExecInitNode() invocation of initial pruning, including those
PartitionPruneResult to carry the result of that pruning for
ExecInitNode()-time reuse, though they no longer need be passed
through many unrelated interfaces.
Anyways, here's a description of the patches:
0001 adjusts various call sites of ExecutorStart() to cope with the
possibility of being asked to recreate a CachedPlan, if one is
involved. The main objective here is to have as little stuff as
sensible happen between GetCachedPlan() that returned the CachedPlan
and ExecutorStart() so as to minimize the chances of missing cleaning
up resources that must not be missed.
0002 is preparatory refactoring to make out-of-ExecInitNode()
invocation of pruning possible.
0003 moves the responsibility of CachedPlan validation locking into
ExecutorStart() as described above.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
