Re: Allowing parallel-safe initplans

On Thu, Apr 13, 2023 at 10:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > * For the diff in standard_planner, I was wondering why not move the
> > initPlans up to the Gather node, just as we did before. So I tried that
> > way but did not notice the breakage of regression tests as stated in the
> > comments. Would you please confirm that?
>
> Try it with debug_parallel_query = regress.

Ah, I see. With DEBUG_PARALLEL_REGRESS the initPlans that move to the
Gather would become invisible along with the Gather node.

As I tried this, I found that the breakage caused by moving the
initPlans to the Gather node might be more than just being cosmetic.
Sometimes it may cause wrong results. As an example, consider

create table a (i int, j int);
insert into a values (1, 1);
create index on a(i, j);

set enable_seqscan to off;
set debug_parallel_query to on;

# select min(i) from a;
min
-----
0
(1 row)

As we can see, the result is not correct. And the plan looks like

# explain (verbose, costs off) select min(i) from a;
QUERY PLAN
-----------------------------------------------------------
Gather
Output: ($0)
Workers Planned: 1
Single Copy: true
InitPlan 1 (returns $0)
-> Limit
Output: a.i
-> Index Only Scan using a_i_j_idx on public.a
Output: a.i
Index Cond: (a.i IS NOT NULL)
-> Result
Output: $0
(12 rows)

The initPlan has been moved from the Result node to the Gather node. As
a result, when doing tuple projection for the Result node, we'd get a
ParamExecData entry with NULL execPlan. So the initPlan does not get
chance to be executed. And we'd get the output as the default value
from the ParamExecData entry, which is zero as shown.

So now I begin to wonder if this wrong result issue is possible to exist
in other places where we move initPlans. But I haven't tried hard to
verify that.

Thanks
Richard