Re: [HACKERS] Measuring replay lag - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] Measuring replay lag
Date
Msg-id CANP8+j+2O7ELaem=S8rbgCAZc9dYthoe+pPahpdkbFNJdx7QpQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Measuring replay lag  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] Measuring replay lag  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On 16 March 2017 at 08:02, Thomas Munro <thomas.munro@enterprisedb.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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4