issue with track_commit_timestamp and server restart
| От | Julien Rouhaud |
|---|---|
| Тема | issue with track_commit_timestamp and server restart |
| Дата | |
| Msg-id | ff10e34a-c85f-3e2b-f07f-c4c4c88fae8b@dalibo.com обсуждение исходный текст |
| Ответы |
Re: issue with track_commit_timestamp and server restart
|
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: