Re: Measuring replay lag

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Measuring replay lag
Date: 2017-03-22 11:03:14
Message-ID: CAEepm=1uDGfwWWrah8qEj3j0ZAZo8kT0Rg0t_B8b0hy9F2JQKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 22, 2017 at 11:57 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> 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".
>
> Thomas, Are you working on another version even? You've not replied to
> me or David, so its difficult to know what next.
>
> Not sure whether this a 6 day lag, or we should show NULL because we
> are up to date.

Hah. Apologies for the delay -- I will post a patch with
documentation as requested within 24 hours.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-03-22 11:12:23 Re: Measuring replay lag
Previous Message Simon Riggs 2017-03-22 10:57:08 Re: Measuring replay lag