Re: Potential (low likelihood) wraparound hazard in heap_abort_speculative() - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Potential (low likelihood) wraparound hazard in heap_abort_speculative()
Date
Msg-id CAH2-Wzmr4MzWzOF-CnaJBo+Ur6fbM+gnQNnRyq187o_-HpSZTg@mail.gmail.com
Whole thread Raw
In response to Potential (low likelihood) wraparound hazard inheap_abort_speculative()  (Andres Freund <andres@anarazel.de>)
Responses Re: Potential (low likelihood) wraparound hazard inheap_abort_speculative()
List 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 by date:

Previous
From: Chapman Flack
Date:
Subject: Re: GSoC Proposal
Next
From: Andres Freund
Date:
Subject: Re: Potential (low likelihood) wraparound hazard inheap_abort_speculative()