Re: PANIC: wrong buffer passed to visibilitymap_clear
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2021-04-13T01:33:19Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes: > On Mon, Apr 12, 2021 at 9:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hence, I propose the attached. It passes check-world, but that proves >> absolutely nothing of course :-(. I wonder if there is any way to >> exercise these code paths deterministically. > This approach seems reasonable to me. At least you've managed to > structure the visibility map page pin check as concomitant with the > existing space recheck. Thanks for looking it over. Do you have an opinion on whether or not to back-patch? As far as we know, these bugs aren't exposed in the back branches for lack of code that would set the all-visible flag without superexclusive lock. But I'd still say that heap_update is failing to honor its API contract in these edge cases, and that seems like something that could bite us after future back-patches. Or there might be third-party code that can set all-visible flags. So I'm kind of tempted to back-patch, but it's a judgment call. regards, tom lane
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