Re: Incorrect result of bitmap heap scan. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Incorrect result of bitmap heap scan.
Date
Msg-id x26gr5c3v5vivjp7dodnrekewmqrpnb2qeaadd5vaxtg3wgnme@mma4l5iencre
Whole thread Raw
In response to Re: Incorrect result of bitmap heap scan.  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2024-12-02 11:07:38 -0500, Peter Geoghegan wrote:
> Clearly it would be wildly impractical to do the "buffer pin interlock
> against TID recycling" thing in the context of bitmap scans.

That's certainly true if we do the VM check at the time of the bitmap heap
scan.

What if we did it whenever we first enter a block into the TID bitmap? There's
sufficient padding space in PagetableEntry to store such state without
increasing memory usage.

That'd probably need some API evolution, because we'd only know after entering
into the tidbitmap that we need to check the VM, we'd need to index pins
during the VM checking and then update PagetableEntry with the result of the
VM probe.

I think, but am not certain, that it'd be sufficient to do the VM check the
first time an index scan encounters a block. If a concurrent vacuum would mark
the heap page all-visible after we encountered it first, we'd do "real"
visibility checks, because the first VM lookup won't have it as all
visible. And in the opposite situation, where we find a page all-visible in
the VM, which then subsequently gets marked not-all-visible, normal snapshot
semantics would make it safe to still consider the contents all-visible,
because update/delete can't be visible to "us".

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Incorrect result of bitmap heap scan.
Next
From: Andres Freund
Date:
Subject: Re: Incorrect result of bitmap heap scan.