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

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Thu, Jan 10, 2019 at 10:04 AM Andrew Gierth
> <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>> But clearly this can't work if one param is referenced both inside and
>> outside a Gather, because while they will compare equal for Vars, they
>> won't actually have the same value thanks to rows coming in from
>> workers.

> But if they used different params, there could be different problems,
> no? It's logically the same var.

As far as I can think at the moment, there's no problem with having
multiple nestloop Params referencing the "same" Var. It could be an
impediment to optimization if it happened (much) earlier in the planner,
but for the situation at hand the only code that's going to be looking
at the tree is the executor and maybe ruleutils, both of which are much
too stupid to be bothered by such aliasing.

> This makes me wonder if we need
> some kind of scheme for saving and restoring affected params whenever
> Gather switches between executing the plan directly and emitting
> tuples from workers, or something like that...

I don't think we need to (or should) go there if this is the only
problem. What's worrying me is what other assumptions based on serial
plan execution are getting broken by injecting Gather into mid levels
of a plan tree.

regards, tom lane