Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Дата
Msg-id CAH2-WznzamB7MK2QQpDGqaPwpg584sG2yrTQrmGTdB9BbQo+wQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Ответы Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
On Thu, Jun 10, 2021 at 9:57 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> > By "matches what we expect", I meant "involves a just-aborted
> > transaction". We could defensively verify that the inserting
> > transaction concurrently aborted at the point of retrying/calling
> > heap_page_prune() a second time. If there is no aborted transaction
> > involved (as was the case with this bug), then we can be confident
> > that something is seriously broken.
>
> I believe there are more cases than only the rolled back case, but
> checking for those cases would potentially help, yes.

Why do you believe that there are other cases?

I'm not aware of any case that causes lazy_scan_prune() to retry using
the goto, other than the aborted transaction case I described
(excluding the bug that you diagnosed, which was of course never
supposed to happen). If it really is possible to observe a retry for
any other reason then I'd very much like to know all the details - it
might well signal a distinct bug of the same general variety.

-- 
Peter Geoghegan



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

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic