Re: BUG #15577: Query returns different results when executedmultiple times

On Tue, Jan 8, 2019 at 1:48 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On Tue, 8 Jan 2019 at 13:43, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
> > It's as if it thought it was executing a semi-join.
>
> EXPLAIN VERBOSE would show the inner_unique flag. If that's set it
> would act as a semi-join.

Hmm, yes, node->js.single_match == true in one (but not both!) process
would fit these results.  But I don't see a mechanism for that.  I
*guess* it's the worker that is skipping duplicates, because the
leader usually has time to emit a few tuples while the worker's
warming up and we see some duplicates (348539) in first few results
(at least it usually does on my machines for eager plans, though maybe
on Windows it's different?)

Bartosz, can we please try with force_parallel_mode = off, but also
parallel_leader_participation = off?  (I meant to write that in an
earlier email but accidentally wrote "on".  Gah.)  Then we should get
the same plan (the forced parallel plan is a bit different as you
noted; maybe whatever is broken isn't triggered that way).  You might
need to set parallel_workers to 2 on the table for it to pick a
parallel plan without leader participation.

-- 
Thomas Munro
http://www.enterprisedb.com