Re: Allowing parallel-safe initplans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allowing parallel-safe initplans
Date
Msg-id 2425967.1681743873@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing parallel-safe initplans  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Allowing parallel-safe initplans  (Richard Guo <guofenglinux@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564
Next
From: Stephen Frost
Date:
Subject: Re: longfin missing gssapi_ext.h