Re: tracking commit timestamps
От | Fujii Masao |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | CAHGQGwFybprq5=27szFJcCjzT7ZzpV7RgRotQS+hXFd8xyW_Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: tracking commit timestamps
Re: tracking commit timestamps |
Список | pgsql-hackers |
On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> And here is v10 which fixes conflicts with Heikki's WAL API changes (no >> changes otherwise). > > After some slight additional changes, here's v11, which I intend to > commit early tomorrow. The main change is moving the test module from > contrib to src/test/modules. When I specify the XID of the aborted transaction in pg_xact_commit_timestamp(), it always returns 2000-01-01 09:00:00+09. Is this intentional? Can I check my understanding? Probably we cannot use this feature to calculate the actual replication lag by, for example, comparing the result of pg_last_committed_xact() in the master and that of pg_last_xact_replay_timestamp() in the standby. Because pg_last_xact_replay_timestamp() can return even the timestamp of aborted transaction, but pg_last_committed_xact() cannot. Right? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: