Re: BUG #15290: Stuck Parallel Index Scan query

On Wed, Jul 25, 2018 at 8:29 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Jul 25, 2018 at 2:08 PM, Andres Freund <andres@anarazel.de> wrote:
>> On 2018-07-25 14:04:11 +1200, Thomas Munro wrote:
>>> Ok, I see it:
>>>
>>>                         /* check for interrupts while we're not
>>> holding any buffer lock */
>>>                         CHECK_FOR_INTERRUPTS();
>>>                         /* step right one page */
>>>                         so->currPos.buf = _bt_getbuf(rel, blkno, BT_READ);
>>>                         ...
>>>                         /* nope, keep going */
>>>                         if (scan->parallel_scan != NULL)
>>>                         {
>>>                                 status = _bt_parallel_seize(scan, &blkno);
>>>
>>> That leads to a condition variable wait, while we still hold that
>>> buffer lock.  That prevents interrupts.  Oops.
>>

Well spotted.  I think here we can release the current page lock
before calling _bt_parallel_seize as we don't need it to get the next
page.  See the backward scan case, in particular, I am referring to
the below code:

_bt_readnextpage()
{
..
* For parallel scans, get the last page scanned as it is quite
* possible that by the time we try to seize the scan, some other
* worker has already advanced the scan to a different page.  We
* must continue based on the latest page scanned by any worker.
*/
if (scan->parallel_scan != NULL)
{
_bt_relbuf(rel, so->currPos.buf);
status = _bt_parallel_seize(scan, &blkno);
..
}

This needs some more analysis.  I will continue the analysis and
shared findings.

Thanks, Thomas for pinging me offlist and including me here.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com