Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> I wonder if we should move the responsibility of truncating the
> SLRU to checkpoint. At the moment, it's done in
> OldSerXidSetActiveSerXmin(), while the callers are holding
> SerializableXactHashLock in exclusive mode. While it'll probably
> go quickly in practice, it still seems like there's a risk of
> stalling all new transactions for a few seconds while that
> happens.
I don't think it can stall new transactions unless they are
DEFERRABLE, but it might stall the COMMIT of the oldest serializable
transaction -- if I'm thinking it through correctly. (If not, I
have another energy drink I can crack open.)
Here's my thinking:
The call in RegisterSerializableTransactionInt() to
OldSerXidSetActiveSerXmin() only happens if there are no active
serializable transactions, so it can't fall into the SLRU truncation
code (I think). I'm not worried about
predicatelock_twophase_recover() because it will only call the
function during startup with no transactions active, so it can't hit
the cleanup code. That leaves SetNewSxactGlobalXmin(), which is
only called from ReleasePredicateLocks(), and only when the last
transaction with the low xmin is being cleaned up. Now, that's only
called around completion of a transaction except when starting a
SERIALIZABLE READ ONLY DEFERRABLE transaction; and if you have
explicitly requested a DEFERRABLE transaction you presumably won't
be astonished by a delay in its startup.
So, I'm not arguing that we shouldn't move the truncation to
checkpoint time, but I think what we're protecting against is disk
I/O at COMMIT time, not transaction startup. Presumably disk I/O at
that point would be less surprising, although perhaps the fact that
it can happen on a read only transaction might surprise someone. Of
course, moving any possible delay from this to a background process
seems like a good thing in general; I just don't know whether it's
worth doing right now, versus adding to a list of possible
enhancements. If you're confident it's safe enough, I'm game.
-Kevin