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 по дате отправления: