On 3/15/17 8:38 PM, Simon Riggs wrote:
On 16 March 2017 at 08:02, Thomas Munro <thomas.mu...@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
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".
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: