On Thu, Apr 6, 2023 at 3:33 Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <amitlangot...@gmail.com> writes: > > While thinking about query view locking in context of [1], I realized > > that we have missed also fixing AcquirePlannerLocks() / > > ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to > > a view, which must be locked the same as RTE_RELATION entries. > > I think you're right about that, because AcquirePlannerLocks is supposed > to reacquire whatever locks parsing+rewriting would have gotten. > However, what's with this hunk? > > @@ -527,7 +527,7 @@ standard_planner(Query *parse, const char > *query_string, int cursorOptions, > result->partPruneInfos = glob->partPruneInfos; > result->rtable = glob->finalrtable; > result->permInfos = glob->finalrteperminfos; > - result->viewRelations = glob->viewRelations; > + result->viewRelations = NIL; > result->resultRelations = glob->resultRelations; > result->appendRelations = glob->appendRelations; > result->subplans = glob->subplans;
Oops, I was working in the wrong local branch. Thanks for pushing. I agree that there’s no live bug as such right now, but still good to be consistent. > -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
