On Fri, Sep 11, 2020 at 8:07 AM Justin Pryzby <pry...@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.
v2-0001-Update-parallel-BTree-scan-state-when-the-scan-ke.patch
Description: Binary data
