On Tue, Jan 19, 2021 at 1:37 PM tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.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. > 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, but I'd expect the cached plan to get invalidated in this case - surely the same potential issue exists in Postgres for the current Parallel SELECT functionality - for example, for a column with a default value that is an expression (which could be altered from being parallel-safe to parallel-unsafe). Regards, Greg Nancarrow Fujitsu Australia
