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 |
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 |