On Tue, Jan 19, 2021 at 1:37 PM tsunakawa.takay@fujitsu.com
<tsunakawa.takay@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
seemsthat 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
triggerwith 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
