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

From: Greg Nancarrow <gregn4422@gmail.com>
> On Fri, Jan 15, 2021 at 7:39 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >Here, it seems we are accessing the relation descriptor without any
> >lock on the table which is dangerous considering the table can be
> >modified in a parallel session. Is there a reason why you think this
> >is safe? Did you check anywhere else such a coding pattern?
> 
> Yes, there's a very good reason and I certainly have checked for the
> same coding pattern elsewhere, and not just randomly decided that
> locking can be ignored.
> 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
thatparse 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.

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


Regards
Takayuki Tsunakawa