Re: Measuring replay lag

Hi Thomas,

On 3/15/17 8:38 PM, Simon Riggs wrote:
> On 16 March 2017 at 08:02, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>
>> I agree that these states exist, but we disagree on what 'lag' really
>> means, or, rather, which of several plausible definitions would be the
>> most useful here.
>>
>> My proposal is that the *_lag columns should always report how long it
>> took for recently written, flushed and applied WAL to be written,
>> flushed and applied (and for the primary to know about it). By this
>> definition, sent LSN = applied LSN is not a special case: we simply
>> report how long that LSN took to be written, flushed and applied.
>>
>> Your proposal is that the *_lag columns should report how far in the
>> past the standby is at each of the three stages with respect to the
>> current end of WAL. By this definition when sent LSN = applied LSN we
>> are currently in the 'A' state meaning 'caught up' and should show
>> 00:00:00.
>
> I accept your proposal for how we handle these, on condition that you
> write up some docs that explain the subtle difference between the two,
> so we can just show people the URL. That needs to explain clearly the
> difference in an impartial way between "what is the most recent lag
> measurement" and "how long until we are caught up" as possible
> intrepretations of these values. Thanks.

This thread has been idle for six days. Please respond and/or post a
new patch by 2017-03-24 00:00 AoE (UTC-12) or this submission will be
marked "Returned with Feedback".

Thanks,
--
-David
david(at)pgmasters(dot)net