Re: Measuring replay lag

On 23 March 2017 at 01:02, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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