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

From Simon Riggs
Subject Re: [HACKERS] Measuring replay lag
Date
Msg-id CANP8+j+g9_HK+3dQ2PwLUwn=j8Oo3muBLhVg5WosHRHpf6OXQw@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  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On 23 March 2017 at 01:02, Thomas Munro <thomas.munro@enterprisedb.com> wrote:

> Thanks!  Please find attached v7, which includes a note we can point
> at when someone asks why it doesn't show 00:00:00, as requested.

Thanks.

Now I look harder the handling for logical lag seems like it would be
problematic in many cases. It's up to the plugin whether it sends
anything at all, so we should make a LagTrackerWrite() call only if
the plugin sends something. Otherwise the lag tracker will just slow
down logical replication.

What I think we should do is add an LSN onto LogicalDecodingContext to
represent the last LSN sent by the plugin, if any.

If that advances after the call to LogicalDecodingProcessRecord() then
we know we just sent a message and we can track that with
LagTrackerWrite().

So we make it the plugin's responsibility to maintain this LSN
correctly, if at all. (It may decide not to)

In English that means the plugin will update the LSN after each
Commit, and since we reply only on commit this will provide a series
of measurements we can use. It will still give a saw-tooth, but its
better than flooding the LagTracker with false measurements.

I think it seems easier to add that as a minor cleanup/open item after
this commit.

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



pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] ANALYZE command progress checker
Next
From: sher-ars@ispras.ru
Date:
Subject: Re: [HACKERS] [GSoC] Push-based query executor discussion