I just noticed that if track_commit_timestamp is enabled, the oldestCommitTsXid and newestCommitTsXid don't persist after a server restart, so you can't ask for the commit ts of a transaction that committed before the last server start, although the information is still available (unless of course if a freeze occured). AFAICT it always behave this way.
I'm not familiar with that code, but it looks like these counters are supposed to be restored in StartupXLOG(), with a call to SetCommitTsLimit(). However, this function doesn't store the new value if ShmemVariableCache->oldestCommitTsXid is InvalidTransactionId, which is the initial value. So the counters are initialized on a subsequent call of ActivateCommitTs(), which does: if (ShmemVariableCache->oldestCommitTsXid == InvalidTransactionId) { ShmemVariableCache->oldestCommitTsXid = ShmemVariableCache->newestCommitTsXid = ReadNewTransactionId(); } (but doesn't try to cleanup the SLRU directory btw) leaving any previous transaction unreachable. Simple attached patch seems to fix the issue. I tried on a master and a replica, enabling and disabling track_commit_timestamp, and everything seemed to work as intended. -- Julien Rouhaud http://dalibo.com - http://dalibo.org
diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c index a8d275f..7746578 100644 --- a/src/backend/access/transam/commit_ts.c +++ b/src/backend/access/transam/commit_ts.c @@ -844,6 +844,8 @@ SetCommitTsLimit(TransactionId oldestXact, TransactionId newestXact) else { Assert(ShmemVariableCache->newestCommitTsXid == InvalidTransactionId); + ShmemVariableCache->oldestCommitTsXid = oldestXact; + ShmemVariableCache->newestCommitTsXid = newestXact; } LWLockRelease(CommitTsLock); }
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers