Re: Potential (low likelihood) wraparound hazard in heap_abort_speculative()

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Potential (low likelihood) wraparound hazard in heap_abort_speculative()
Дата
Msg-id CAH2-Wzmr4MzWzOF-CnaJBo+Ur6fbM+gnQNnRyq187o_-HpSZTg@mail.gmail.com
обсуждение исходный текст
Ответ на Potential (low likelihood) wraparound hazard inheap_abort_speculative()  (Andres Freund <andres@anarazel.de>)
Ответы Re: Potential (low likelihood) wraparound hazard inheap_abort_speculative()  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Sat, Mar 28, 2020 at 2:30 PM Andres Freund <andres@anarazel.de> wrote:
> Unless somebody has a better idea for how to solve this in a
> back-paptchable way, I think it'd be best to replace RecentGlobalXmin
> with RecentXmin. That'd be safe as far as I can see.

As far as I can tell, the worst consequence of this wraparound hazard
is that we don't opportunistically prune at some later point where we
probably ought to. Do you agree with that assessment?

Since pd_prune_xid is documented as "a hint field" in bufpage.h, this
bug cannot possibly lead to queries that give wrong answers. The
performance issue also seems like it should not have much impact,
since we only call heap_abort_speculative() in extreme cases where
there is a lot of contention among concurrent upserting sessions.
Also, as you pointed out already, RecentGlobalXmin is probably not
going to be any different to RecentXmin.

I am in favor of fixing the issue, and backpatching all the way. I
just want to put the issue in perspective, and have my own
understanding of things verified.

-- 
Peter Geoghegan



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

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: GSoC Proposal
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Potential (low likelihood) wraparound hazard inheap_abort_speculative()