Re: Avoiding superfluous buffer locking during nbtree backwards scans

From: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: Avoiding superfluous buffer locking during nbtree backwards scans
Date: 2024-11-08 13:25:48
Message-ID: 639613b3dd64dd67ed20fdd55ded1408@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-11-08 13:33:23 Re: magical eref alias names
Previous Message Alvaro Herrera 2024-11-08 13:08:10 Re: not null constraints, again