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

From Peter Geoghegan
Subject Re: PANIC: wrong buffer passed to visibilitymap_clear
Date
Msg-id CAH2-Wz=_u6ObPqg1Ar638U2CB6thvuni=StjLQ7iniuKX9YZdA@mail.gmail.com
Whole thread Raw
In response to Re: PANIC: wrong buffer passed to visibilitymap_clear  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PANIC: wrong buffer passed to visibilitymap_clear
List pgsql-hackers
On Sun, Apr 11, 2021 at 10:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alternatively, we could do what you suggested and redefine things
> so that one is only allowed to set the all-visible bit while holding
> superexclusive lock; which again would allow an enormous simplification
> in heap_update and cohorts.

Great detective work.

I would rather not go back to requiring a superexclusive lock in
vacuumlazy.c (outside of pruning), actually -- I was only pointing out
that that had changed, and was likely to be relevant. It wasn't a real
proposal.

I think that it would be hard to justify requiring a super-exclusive
lock just to call PageSetAllVisible(). PD_ALL_VISIBLE is fundamentally
redundant information, so somehow it feels like the wrong design.

> 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.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
Next
From: Tom Lane
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear