On Sat, Nov 7, 2026 at 7:40 PM Pierre Forstmann <[email protected]>
wrote:
> Hello,
>
> This patch looks good to me.
>
> I have applied it on latest 20-devel master branch and I have run make
> installcheck-world successfully.
>
> I have set status to Ready For Committed.
>
Thanks, Pierre.
> Regards,
>
> PF.
> Le 26/10/2026 à 09:58, Jeevan Chalke a écrit :
>
> 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>
>
>
--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*
enterprisedb.com <https://www.enterprisedb.com>
