On Sun, Apr 11, 2021 at 11:16 AM Tom Lane <t...@sss.pgh.pa.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
