Small bug in replication lag tracking

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