From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sync Rep v19 |
Date: | 2011-03-11 13:21:52 |
Message-ID: | AANLkTi=WTHOvL2PtS=2U_eW4GxoM82VDOBWk-255fxQk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas <robertmhaas(at)gmail(dot)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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-03-11 13:28:15 | Re: Typed-tables patch broke pg_upgrade |
Previous Message | Robert Haas | 2011-03-11 13:18:22 | Re: Replication server timeout patch |