[HACKERS] Small bug in replication lag tracking

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема [HACKERS] Small bug in replication lag tracking
Дата
Msg-id CAEepm=3tJX_0kSeDi8OYTMp8NogrqPxgP1+2uzsdePz9i0-V0Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: [HACKERS] Small bug in replication lag tracking  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Hi,

I discovered a thinko in the new replication lag interpolation code
that can cause a strange number to be reported occasionally.

The interpolation code is designed to report increasing lag when
replay gets stuck somewhere between two LSNs for which we have
timestamp samples.  The bug is that after sitting idle and fully
replayed for a while and then encountering a new burst of WAL
activity, we interpolate between an ancient sample and the
not-yet-reached one for the new traffic, which is inappropriate.  It's
hard to see obviously strange lag times, because they normally only
exist for a very short moment in between receiving the first and
second replies from the standby, and they often look reasonable even
if you do manage to catch one in pg_stat_replication.  You can see the
problem by pausing replay on the the standby in between two bursts of
WAL with a long period of idleness in between.

Please find attached a patch to fix that, with comments to explain.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Fix a typo in partition.c
Следующее
От: Yugo Nagata
Дата:
Сообщение: Re: [HACKERS] [POC] hash partitioning