Re: master-side counterpart of pg_last_xact_replay_timestamp?

On Thu, Sep 8, 2011 at 3:19 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, Sep 8, 2011 at 6:43 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Your complaint makes sense. I'll implement something like
>> pg_last_xact_timestamp() for 9.2. But unfortunately there is
>> no way to know such a timestamp on the master, in 9.1..
>
>
> I see the reason, but would be against that change.
>
> We don't currently generate a timestamp for each WAL record. Doing so
> would be a performance drain and a contention hotspot.

Each commit/abort record already has a timestamp. So I'm thinking to
implement pg_last_xact_insert_timestamp() so that it returns the
timestamp of the last inserted commit/abort record. Since we don't
need to generate a timestamp newly, I guess that what I'm thinking to
implement would not degrade a performance.

pg_last_xact_replay_timestamp() also returns the timestamp of the
commit/abort record replayed. So pg_last_xact_insert_timestamp()
doesn't need to return the timestamp other than that of commit/abort
record, to compare them to calculate the replication delay.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center