From: Greg Nancarrow <gregn4...@gmail.com> > On Fri, Jan 15, 2021 at 7:39 PM Amit Kapila <amit.kapil...@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 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. 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? Regards Takayuki Tsunakawa
