Skip to content

Commit ff8ce0b

Browse files
author
Amit Kapila
committed
Fix the buffer release order for parallel index scans.
During parallel index scans, if the current page to be read is deleted, we skip it and try to get the next page for a scan without releasing the buffer lock on the current page. To get the next page, sometimes it needs to wait for another process to complete its scan and advance it to the next page. Now, it is quite possible that the master backend has errored out before advancing the scan and issued a termination signal for all workers. The workers failed to notice the termination request during wait because the interrupts are held due to buffer lock on the previous page. This lead to all workers being stuck. The fix is to release the buffer lock on current page before trying to get the next page. We are already doing same in backward scans, but missed it for forward scans. Reported-by: Victor Yegorov Bug: 15290 Diagnosed-by: Thomas Munro and Amit Kapila Author: Amit Kapila Reviewed-by: Thomas Munro Tested-By: Thomas Munro and Victor Yegorov Backpatch-through: 10 where parallel index scans were introduced Discussion: https://postgr.es/m/153228422922.1395.1746424054206154747@wrigleys.postgresql.org
1 parent 46201d6 commit ff8ce0b

File tree

1 file changed

+4
-2
lines changed

1 file changed

+4
-2
lines changed

src/backend/access/nbtree/nbtsearch.c

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1495,17 +1495,19 @@ _bt_readnextpage(IndexScanDesc scan, BlockNumber blkno, ScanDirection dir)
14951495
/* nope, keep going */
14961496
if (scan->parallel_scan != NULL)
14971497
{
1498+
_bt_relbuf(rel, so->currPos.buf);
14981499
status = _bt_parallel_seize(scan, &blkno);
14991500
if (!status)
15001501
{
1501-
_bt_relbuf(rel, so->currPos.buf);
15021502
BTScanPosInvalidate(so->currPos);
15031503
return false;
15041504
}
15051505
}
15061506
else
1507+
{
15071508
blkno = opaque->btpo_next;
1508-
_bt_relbuf(rel, so->currPos.buf);
1509+
_bt_relbuf(rel, so->currPos.buf);
1510+
}
15091511
}
15101512
}
15111513
else

0 commit comments

Comments
 (0)