On Fri, Mar 24, 2017 at 5:57 AM, Rafia Sabih <rafia.sa...@enterprisedb.com> wrote: >> I suspect that code fails to achieve its goals anyway. At the top of >> exec_eval_expr(), you call exec_prepare_plan() and unconditionally >> pass CURSOR_OPT_PARALLEL_OK, so when that function returns, expr->plan >> might now be a parallel plan. If we reach the call to >> exec_run_select() further down in that function, and if we happen to >> pass false, it's not going to matter, because exec_run_select() is >> going to find the plan already initialized. >> > True, fixed. > The attached patch is to be applied over [1].
After some scrutiny I didn't find anything particularly wrong with this, with the exception that exec_eval_expr() was passing false as the parallelOK argument to exec_run_select(), which is inconsistent with that function's earlier use of CURSOR_OPT_PARALLEL_OK to plan the same query. I fixed that by ripping out the parallelOK argument altogether and just passing CURSOR_OPT_PARALLEL_OK when portalP == NULL. The only reason I added parallelOK in the first place was because of that RETURN QUERY stuff which subsequent study has shown to be misguided. Committed that way; please let me know if you see any problems. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
