Re: BUG #15577: Query returns different results when executed multiple times

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 9, 2019 at 5:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> One way we could deal with this, perhaps, is to decide that NestLoopParams
>> above and below a Gather can't share PARAM_EXEC slots. I'm not sure how
>> we'd mechanize that, other than not allowing NestLoopParams to share
>> PARAM_EXEC slots *ever*, which might not really be that much of a cost.
>>
>> But TBH the whole thing frightens me quite a lot as to what other
>> serial-processing assumptions are getting broken by plopping Gather
>> into the middle of a plan tree. I wonder whether we'd not be best
>> off disallowing this sort of plan shape, and/or forbidding the leader
>> from also executing the parallelized subplan.

> FWIW, I would be inclined to blame this on me not really understanding
> the Param machinery very well rather than any more general brand of
> insanity. I wouldn't be a bit shocked if this is not the last bit
> Param-related dumbness than parallel query has. I did *try* to get it
> right, but I find that stuff to be pretty arcane and not entirely
> well-documented.

Well, if we posit that the problems are limited to false Param-sharing,
my inclination is to fix it by simplifying rather than adding complexity.
To wit, let's just assign a new PARAM_EXEC slot for every NestLoopParam
and never try to share them. The argument that sharing them would work
for NLPs representing the same Var hinged on the assumption that nested
NestLoops would necessarily execute "in sync", which we now see is false
at least when Gathers are in between.

This'll cost some more PARAM_EXEC slots, of course, but AFAICS the
cost of that is trivial, just a few more bytes per slot. It's arguable
that the cost of trying to de-duplicate them at plan time is more than
we can save at execution :-(

I'm about fried for tonight, but I can take a look at this tomorrow.

regards, tom lane