On Mon, Dec 11, 2017 at 8:14 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Dec 11, 2017 at 8:21 AM, Thomas Munro
> <thomas.munro@enterprisedb.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