Re: PANIC: wrong buffer passed to visibilitymap_clear

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PANIC: wrong buffer passed to visibilitymap_clear
Дата
Msg-id 3139938.1618277599@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PANIC: wrong buffer passed to visibilitymap_clear  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: PANIC: wrong buffer passed to visibilitymap_clear
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: TRUNCATE on foreign table
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: PANIC: wrong buffer passed to visibilitymap_clear