Re: Parallel INSERT (INTO ... SELECT ...)

On Tue, Jan 19, 2021 at 10:32 AM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> On Tue, Jan 19, 2021 at 1:37 PM tsunakawa(dot)takay(at)fujitsu(dot)com
> <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
> >
> > > The table has ALREADY been locked (by the caller) during the
> > > parse/analyze phase.
> >
> > Isn't there any case where planning is done but parse analysis is not done immediately before? e.g.
> >
> > * Alteration of objects invalidates cached query plans, and the next execution of the plan rebuilds it. (But it seems that parse analysis is done in this case in plancache.c.)
> >
> > * Execute a prepared statement with a different parameter value, which builds a new custom plan or a generic plan.
> >
>
> I don't know, but since NoLock is used in other parts of the planner,
> I'd expect those to fail if such cases existed.
>

I think I know how for both the above cases, we ensure that the locks
are acquired before we reach the planner. It seems we will call
GetCachedPlan during these scenarios which will acquire the required
locks in RevalidateCachedQuery both when the cached plan is invalid
and when it is valid. So, we should be fine even when the
custom/generic plan needs to be formed due to a different parameter.

> > Is the cached query plan invalidated when some alteration is done to change the parallel safety, such as adding a trigger with a parallel-unsafe trigger action?
> >
>
> Needs to be tested,
>

Yeah, it would be good to test it but I think even if the plan is
invalidated, we will reacquire the required locks as mentioned above.

Tsunakawa-San, does this address your concerns around locking the
target relation in the required cases? It would be good to test but I
don't see any problems in the scenarios you mentioned.

--
With Regards,
Amit Kapila.