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
