Heikki Linnakangas <heikki.linnakan...@enterprisedb.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
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
