Re: What constrains the range of SERIALIZABLEXACT xmin values?

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