Re: [HACKERS] Measuring replay lag

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] Measuring replay lag
Дата
Msg-id CANP8+j+g9_HK+3dQ2PwLUwn=j8Oo3muBLhVg5WosHRHpf6OXQw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Measuring replay lag  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] Measuring replay lag
Список 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 по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: [HACKERS] ANALYZE command progress checker
Следующее
От: sher-ars@ispras.ru
Дата:
Сообщение: Re: [HACKERS] [GSoC] Push-based query executor discussion