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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Greg Nancarrow <gregn4422(at)gmail(dot)com>
Cc: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Date: 2021-01-19 06:15:05
Message-ID: CAA4eK1Js5gUkHkuAcnL=1HJ2_tdvSuCiZMMPprauugA0JtXPWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2021-01-19 06:16:07 How to expose session vs txn lock info in pg_locks view?
Previous Message Tom Lane 2021-01-19 06:12:11 Re: [PATCH 1/1] Initial mach based shared memory support.