Re: tracking commit timestamps - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: tracking commit timestamps
Date
Msg-id CAHGQGwFybprq5=27szFJcCjzT7ZzpV7RgRotQS+hXFd8xyW_Ww@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: tracking commit timestamps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: tracking commit timestamps  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Missing OOM checks in libpq (was Re: Replication connection URI?)
Next
From: Alex Shulgin
Date:
Subject: Re: Missing OOM checks in libpq (was Re: Replication connection URI?)