On Fri, Mar 11, 2011 at 8:21 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> How about sending the timestamp of last applied transaction
>>> (i.e., this is the return value of pg_last_xact_replay_timestamp)
>>> from the standby to the master, and reporting it in
>>> pg_stat_replication? Then you can see the lag by comparing
>>> it with current_timestamp.
>>>
>>> But since the last replay timestamp doesn't advance (but
>>> current timestamp advances) if there is no work on the master,
>>> the calculated lag might be unexpectedly too large. So, to
>>> calculate the exact lag, I'm thinking that we should introduce
>>> new function which returns the timestamp of the last transaction
>>> written in the master.
>>>
>>> Thought?
>>
>> Hmm... where would we get that value from?
>
> xl_xact_commit->xact_time (which is set in RecordTransactionCommit)
> and xl_xact_abort->xact_time (which is set in RecordTransactionAbort).
>
>> And what if no
>> transactions are running on the master?
>
> In that case, the last write WAL timestamp would become equal to the
> last replay WAL timestamp. So we can see that there is no lag.
Oh, I see (I think). You're talking about write/replay lag, but I was
thinking of master/slave transmission lag.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
