On Fri, Sep 11, 2020 at 8:07 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> Against all odds, I was able to reproduce this.
>
Thanks, this helps me to understand the problem. So whats going on
here is that once one of the workers has moved to the next set of scan
keys without incrementing parallel shared key count the other workers
can try to join the on-going scan with a different set of keys which
can lead to unpredictable behavior which is seen by both you and
James. In your case, it scanned the blocks twice for the same set of
scan keys due to which you are getting more rows than actual rows to
be returned by scan and in the case of James, one of the workers
changed it scan block to InvalidBlockNumber (basically start of scan)
during the scan which lead to the problem.
So the fix provided by James is correct. I have slightly adjusted the
commit message in the attached. It needs to be backpatched till 10
where this feature was introduced.
I have tested this on HEAD. It would be great if you can verify in
back branches as well. I'll also do it before commit.
--
With Regards,
Amit Kapila.
