Re: PANIC: wrong buffer passed to visibilitymap_clear
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-11T18:07:33Z
Lists: 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
Commits
-
Avoid improbable PANIC during heap_update.
- 5f12bc94dcc6 12.7 landed
- 37e76546a2ba 13.3 landed
- 34f581c39e97 14.0 landed
-
Refactor lazy_scan_heap() loop.
- 7ab96cf6b312 14.0 cited