On 2024-11-08 07:42, Peter Geoghegan wrote:
Attached revision v2 pushes the fix further in this direction. It
explicitly documents that parallel _bt_readnextpage callers are
allowed to use their so->currPos state (including
blkno/nextPage/prevPage) to help _bt_readnextpage to decide whether it
can end the scan right away. However, parallel index scan callers
still won't be allowed to use this same so->currPos state to decide
what page to go to next -- _bt_readnextpage really will need to seize
the scan to get an authoritative blkno to make that part safe
(actually, one parallel scan _bt_readnextpage caller still seizes the
scan for itself, which is the one caller where _bt_readnextpage fully
trusts caller's blkno + lastcurrblkno).
Thank you! I've confirmed that the v2 patch fixed the bug. As you
mentioned, I also feel that the v2 patch is now easier to understand.
Since I couldn't understand the reason, I have a question: is the
following deletion related to this change?
@@ -770,7 +785,7 @@ _bt_parallel_done(IndexScanDesc scan)
/*
* Should not mark parallel scan done when there's still a
pending
- * primitive index scan (defensive)
+ * primitive index scan
*/
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
