pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
Date: Sun, 11 Apr 2021 14:16:19 -0400
Message-ID: <2692613.1618164979@sss.pgh.pa.us> (raw)
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>

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





view thread (25+ messages)  latest in thread

Message-ID: <2692613.1618164979@sss.pgh.pa.us>
Permalink:  ../2692613.1618164979@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2692613.1618164979@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
  Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
  In-Reply-To: <2692613.1618164979@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox