Re: [PATCH] Transaction traceability - txid_status(bigint)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Petr Jelinek <petr@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Jim Nasby <Jim.Nasby@bluetreble.com>, Álvaro Herrera <alvaro.herrera@2ndquadrant.com>
Date: 2017-01-24T15:49:57Z
Lists: pgsql-hackers
On Mon, Jan 23, 2017 at 1:32 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > Rebased patch attached. I've split the clog changes out from > txid_status() its self. I think it's fairly surprising that TruncateCLOG() has responsibility for writing the xlog record that protects advancing ShmemVariableCache->oldestXid, but not the responsibility for actually advancing that value. In other words, I think the AdvanceOldestXid() call in vac_truncate_clog() should be moved into TruncateClog(). (Similarly, one wonders why AdvanceOldestCommitTsXid() isn't the responsibility of TruncateCommitTs().) I think it is not correct to advance oldestXid but not oldestXidDB. Otherwise, GetNewTransactionId() might complain about the wrong database. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Add a txid_status function.
- 857ee8e391ff 10.0 landed
-
Track the oldest XID that can be safely looked up in CLOG.
- ea42cc18c353 10.0 landed