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