Re: PANIC: wrong buffer passed to visibilitymap_clear - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PANIC: wrong buffer passed to visibilitymap_clear
Date
Msg-id 2692613.1618164979@sss.pgh.pa.us
Whole thread Raw
In response to Re: PANIC: wrong buffer passed to visibilitymap_clear  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: PANIC: wrong buffer passed to visibilitymap_clear  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Sun, Apr 11, 2021 at 10:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Either way, it's hard to argue that
>> heap_update hasn't crossed the complexity threshold where it's
>> impossible to maintain safely.  We need to simplify it.

> It is way too complicated. I don't think that I quite understand your
> first proposal right now, so I'll need to go think about it.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
Next
From: Peter Geoghegan
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear