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

From Thomas Munro
Subject Re: [HACKERS] Measuring replay lag
Date
Msg-id CAEepm=29+7DAzmsy1bC6cSbNibjYyKX9dq7zDOVG0AyObz5yYw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Measuring replay lag  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] Measuring replay lag  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Thu, Mar 23, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Second thoughts... I'll just make LagTrackerWrite externally
>> available, so a plugin can send anything it wants to the tracker.
>> Which means I'm explicitly removing the "logical replication support"
>> from this patch.
>
> Done.
>
> Here's the patch I'm looking to commit, with some docs and minor code
> changes as discussed.

Thank you for committing this.  Time-based replication lag tracking
seems to be a regular topic on mailing lists and IRC, so I hope that
this will provide what people are looking for and not simply replace
that discussion with a new discussion about what lag really means :-)

Many thanks to Simon and Fujii-san for convincing me to move the
buffer to the sender (which now seems so obviously better), to
Fujii-san for the idea of tracking write and flush lag too, and to
Abhijit, Sawada-san, Ian, Craig and Robert for valuable feedback.

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4