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 = 

(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)
 		Assert(ShmemVariableCache->newestCommitTsXid == InvalidTransactionId);
+		ShmemVariableCache->oldestCommitTsXid = oldestXact;
+		ShmemVariableCache->newestCommitTsXid = newestXact;
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to