What constrains the range of SERIALIZABLEXACT xmin values?
Hi,
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).
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