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
fix-lag-interpolation-bug.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
