Horton

Re: Allowing parallel-safe initplans

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-04-17T15:04:33Z
Lists: pgsql-hackers 
Richard Guo <guofenglinux@gmail.com> writes:
> So now it seems that the breakage of regression tests is more severe
> than being cosmetic.  I wonder if we need to update the comments to
> indicate the potential wrong results issue if we move the initPlans to
> the Gather node.

I wondered about that too, but how come neither of us saw non-cosmetic
failures (ie, actual query output changes not just EXPLAIN changes)
when we tried this?  Maybe the case is somehow not exercised, but if
so I'm more worried about adding regression tests than comments.

I think actually that it does work beyond the EXPLAIN weirdness,
because since e89a71fb4 the Gather machinery knows how to transmit
the values of Params listed in Gather.initParam to workers, and that
is filled in setrefs.c in a way that looks like it'd work regardless
of whether the Gather appeared organically or was stuck on by the
debug_parallel_query hackery.  I've not tried to verify that
directly though.

			regards, tom lane

Commits

  1. Account for optimized MinMax aggregates during SS_finalize_plan.

  2. Add test case showing that commit d0d44049d fixed a live bug.

  3. Allow plan nodes with initPlans to be considered parallel-safe.

  4. Allow parallel workers to execute subplans.

  5. Mark a query's topmost Paths parallel-unsafe if they will have initPlans.