Re: master-side counterpart of pg_last_xact_replay_timestamp? - Mailing list pgsql-general

From Fujii Masao
Subject Re: master-side counterpart of pg_last_xact_replay_timestamp?
Date
Msg-id CAHGQGwFHYKTJfX9Yk1zSydEtj7RB3EPrG1HEXQt3ZBi6UqzLYw@mail.gmail.com
Whole thread Raw
In response to Re: master-side counterpart of pg_last_xact_replay_timestamp?  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-general
On Thu, Sep 8, 2011 at 3:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Thu, Sep 8, 2011 at 6:43 AM, Fujii Masao <masao.fujii@gmail.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

pgsql-general by date:

Previous
From: Adarsh Sharma
Date:
Subject: Select Output in XML format
Next
From: Craig Ringer
Date:
Subject: Re: Select Output in XML format