issue with track_commit_timestamp and server restart

From: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: issue with track_commit_timestamp and server restart
Date: 2016-10-22 11:51:58
Message-ID: ff10e34a-c85f-3e2b-f07f-c4c4c88fae8b@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
fix_committs.diff text/x-diff 535 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-10-22 15:39:27 Re: Aggregate Push Down - Performing aggregation on foreign server
Previous Message Ashutosh Bapat 2016-10-22 08:19:35 Re: Push down more full joins in postgres_fdw