From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PANIC: wrong buffer passed to visibilitymap_clear |
Date: | 2021-04-13 01:33:19 |
Message-ID: | 3139938.1618277599@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Mon, Apr 12, 2021 at 9:19 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-04-13 01:54:44 | Re: PANIC: wrong buffer passed to visibilitymap_clear |
Previous Message | Bharath Rupireddy | 2021-04-13 01:21:03 | Re: TRUNCATE on foreign table |