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
