On Wed, Dec 21, 2016 at 3:02 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > Instead, I've added a new LWLock, ClogTruncationLock, for that > purpose. vac_truncate_clog() takes it if it decides to attempt clog > truncation. This lock is held throughout the whole process of clog > truncation and oldestXid advance, so there's no need for a new > pendingOldestXid field in ShmemVariableCache. We just take the lock > then look at oldestXid, knowing that it's guaranteed to correspond to > an existing clog page that won't go away while we're looking. > ClogTruncationLock is utterly uncontested so it's going to have no > meaningful impact compared to all the work we do scanning the clog to > decide whether we're even going to try truncating it, etc.
That makes everything that happens between when we acquire that lock and when we release it non-interruptible, which seems undesirable. I think that extra copy of oldestXid is a nicer approach. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
