Re: What constrains the range of SERIALIZABLEXACT xmin values? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: What constrains the range of SERIALIZABLEXACT xmin values?
Date
Msg-id 20191212214425.mjptyt2eg3bdlssu@alap3.anarazel.de
Whole thread Raw
In response to What constrains the range of SERIALIZABLEXACT xmin values?  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Hi,

On 2019-12-13 10:30:19 +1300, Thomas Munro wrote:
> Every SERIALIZABLEXACT holds an xmin that comes from a Snapshot, and
> SxactGlobalXmin holds the oldest of them.  But a SERIALIZABLEXACT can
> live longer than a transaction and snapshot, so now I'm wondering if
> it's possible to reach a state where there exist SERIALIZABLEXACT
> objects with a range of xmin values that break the modular
> TransactionIdPrecedes()-based logic in SetNewSxactGlobalXmin(), which
> relies on the set of values not spanning more than half of the 2^32
> clock.  If that state is reachable, then I think the effect would be
> to call ClearOldPredicateLocks() at the wrong times (too much and
> we'll waste CPU in that function, not enough and we'll "leak"
> predicate locks by not cleaning them up as eagerly as we intended).

I have only a weak grasp of the details of serializable, so maybe I'm
entirely off base here: Can there actually be SERIALIZABLEXACT entries
with xmins that don't also exist in the table? I'd think that the fact
that rows with the relevant xmins won't commonly be removable would
possibly provide enough interlock?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Make autovacuum sort tables in descending order of xid_age
Next
From: Mark Dilger
Date:
Subject: Re: Make autovacuum sort tables in descending order of xid_age