Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Dec 11, 2017 at 8:21 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> ... and then it called _bt_parallel_seize() itself, in violation of
>> the rule (by my reading of the code) that you must call
>> _bt_parallel_release() (via _bt_readpage()) or _bt_parallel_done()
>> after seizing the scan. If you call _bt_parallel_seize() again
>> without doing that first, you'll finish up waiting for yourself
>> forever. Does this theory make sense?
>>
>
> Yes, I think if the current page is half-dead or deleted, we need to
> set the next page to be scanned and release the parallel scan. This
> has to be done for both forward and backward scans.

Your patch seems to match what _bt_readpage() would do in the regular
live page path, namely _bt_parallel_release(scan, opaque->btpo_next)
to advance to the right and _bt_parallel_release(scan,
BufferGetBlockNumber(so->currPos.buf)) to advance to the left. I
haven't tested it, but it certainly looks correct on that basis (I
admit that the asymmetry threw me for a moment but I get it now).

> Thanks for looking into it. I will see if we can write some test. In
> the meantime if possible, can you please request Patrick Hemmer to
> verify the attached patch?

Our discussion was on the #postgresql Freenode channel. I pointed him
at this thread, but I'm not sure if he'll see my message or be able to
test.

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