Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint) |
Дата | |
Msg-id | CA+TgmobDUczDrBOp_0aCff_Pv8pvFyqsU9HU_S6eK3gwE3R6WQ@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, Jan 25, 2017 at 12:44 AM, Craig Ringer <craig@2ndquadrant.com> wrote: >> The way that SetTransactionIdLimit() now works looks a bit dangerous. >> xidWrapLimit, xidStopLimit, and xidWarnLimit are computed based on the >> passed-in oldestXid value and written straight into shared memory. >> But the shared memory copy of oldestXid could have a different value. >> I'm not sure if that breaks anything, but it certainly weakens any >> confidence callers might have had that all those values are consistent >> with each other. > > This was my main hesitation with the whole thing too. > > It's necessary to advance oldestXmin before we xlog the advance and > truncate clog, and necessary to advance the vacuum limits only > afterwards. Well, that's why I tried to advocate that their should be two separate XID limits in shared memory: leave what's there now the way it is, and then add a new limit for "don't try to look up XIDs before this point: splat". I still think that'd be less risky. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: