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  (Craig Ringer <craig@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Push down more full joins in postgres_fdw
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Aggregate Push Down - Performing aggregation on foreign server