Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint) |
Дата | |
Msg-id | CA+TgmoZY8PSYH9eib_1Pt9-19S1_321XKJz+AHD8uvXEYc3Meg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint) (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)
|
Список | pgsql-hackers |
On Wed, Dec 21, 2016 at 3:02 AM, Craig Ringer <craig@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
В списке pgsql-hackers по дате отправления: