Re: Measuring replay lag

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.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services