From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Andres Freund <andres@anarazel.de>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
In-reply-to: 
 <CAH2-Wz=_u6ObPqg1Ar638U2CB6thvuni=StjLQ7iniuKX9YZdA@mail.gmail.com>
References: <2247102.1618008027@sss.pgh.pa.us>
 <20210409232739.sazp5p4xnnagrusa@alap3.anarazel.de>
 <20210409233203.3khg3s5iw34g4xrc@alap3.anarazel.de>
 <2644575.1618117467@sss.pgh.pa.us>
 <CAH2-WzmWOLaWhQgEC1BJN0JZpOCOwxCAhjmd2Nd4yh4wrqju8Q@mail.gmail.com>
 <2679216.1618156670@sss.pgh.pa.us>
 <CAH2-WzmJ7THDU3jPgRH8J++b+pSoOh8nfGZEhNHh+4=LFatDeg@mail.gmail.com>
 <CAH2-WzkCXg6RQJdc_7ZGHcKvyoJAfFu9R2ZVAiE9mCcOfaXJdQ@mail.gmail.com>
 <2689873.1618161194@sss.pgh.pa.us> <2691106.1618162892@sss.pgh.pa.us>
 <2691724.1618163730@sss.pgh.pa.us>
 <CAH2-Wz=_u6ObPqg1Ar638U2CB6thvuni=StjLQ7iniuKX9YZdA@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Sun, 11 Apr 2021 11:07:33 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2692612.1618164979.1@sss.pgh.pa.us>
Date: Sun, 11 Apr 2021 14:16:19 -0400
Message-ID: <2692613.1618164979@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2692613.1618164979%40sss.pgh.pa.us>
Precedence: bulk

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