Re: PANIC: wrong buffer passed to visibilitymap_clear

On Sun, Apr 11, 2021 at 11:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It wasn't very clear, because I hadn't thought it through very much;
> but what I'm imagining is that we discard most of the thrashing around
> all-visible rechecks and have just one such test somewhere very late
> in heap_update, after we've successfully acquired a target buffer for
> the update and are no longer going to possibly need to release any
> buffer lock. If at that one point we see the page is all-visible
> and we don't have the vmbuffer, then we have to release all our locks
> and go back to "l2". Which is less efficient than some of the existing
> code paths, but given how hard this problem is to reproduce, it seems
> clear that optimizing for the occurrence is just not worth it.

Oh! That sounds way better.

This reminds me of the tupgone case that I exorcised from vacuumlazy.c
(in the same commit that stopped using a superexclusive lock). It was
also described as an optimization that wasn't quite worth it. But I
don't quite buy that. ISTM that there is a better explanation: it
evolved the appearance of being an optimization that might make sense.
Which was just camouflage.

--
Peter Geoghegan