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

Thomas, I tried to reproduce this case with changes you listed, but failed
to do that - the number of results was the same on each run. Could you post
an updated script in an attachment?

On Wed, Jan 9, 2019 at 5:01 AM Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
wrote:

> On Wed, Jan 9, 2019 at 2:52 PM Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> > Now the number of results from the query in the script is not stable,
> > varying between 235 or 246 results for me. Not sure what's going on
> > yet.
>
> When there are multiple matches found by the Index Scan, sometimes
> only the first one makes it through to the Nested Loop, in the leader.
> It's not because of single_match being inappropriately set as I
> speculated earlier (though that'd behave similarly I guess) but
> because the quals are somehow broken in between invocations so that
> ExecScan() filters the rest of the matches out, and then fixed again
> on the next rescan. This happens whenever the leader takes a break to
> read tuple from parallel workers in between executing the Nested Loop
> node, which it often does after reading the first of several tuples
> resulting from a single rescan.
>
> What exactly is being corrupted and how, I don't yet know, and I need
> to leave this here for today, but that's what I've got so far.
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>