Hi,
Commit 61c2e1a95f ("Improve access to parallel query from procedural
languages") made exec_eval_expr() prepare expressions with
CURSOR_OPT_PARALLEL_OK, so that queries in IF, RETURN, RAISE, etc. can use
parallel plans. It missed exec_assign_expr(), which creates the plan
itself,
with cursorOptions 0, before calling exec_eval_expr(). As the plan already
exists by then, the PARALLEL_OK prepare in exec_eval_expr() never runs.
As a result, a query used in an assignment never gets a parallel plan:
x := sum(a) from tab;
while the same query used in, say, an IF condition can. The same applies to
DECLARE default expressions, which also go through exec_assign_expr().
The pre-planning in exec_assign_expr() is redundant, since exec_eval_expr()
creates the plan if needed, so the attached patch just removes it.
The patch also adds regression tests to select_parallel.sql, one for an
assignment statement and one for a DECLARE default. Each provokes an error
in a worker with debug_parallel_query = 1 and checks for the "parallel
worker" context line. Both tests fail without the fix.
Thoughts?
Thanks
--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*
enterprisedb.com <https://www.enterprisedb.com>
v1-0001-Allow-parallel-query-for-PL-pgSQL-assignment-stat.patch
Description: Binary data
