Re: PANIC: wrong buffer passed to visibilitymap_clear

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PANIC: wrong buffer passed to visibilitymap_clear
Дата
Msg-id 2692613.1618164979@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 Sun, Apr 11, 2021 at 10:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

It wasn't very clear, because I hadn't thought it through very much;
but what I'm imagining is that we discard most of the thrashing around
all-visible rechecks and have just one such test somewhere very late
in heap_update, after we've successfully acquired a target buffer for
the update and are no longer going to possibly need to release any
buffer lock.  If at that one point we see the page is all-visible
and we don't have the vmbuffer, then we have to release all our locks
and go back to "l2".  Which is less efficient than some of the existing
code paths, but given how hard this problem is to reproduce, it seems
clear that optimizing for the occurrence is just not worth it.

            regards, tom lane



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

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