Why does pg_last_xact_replay_timestamp() sometimes return extremely old timestamps? In PostgreSQL 9.5, to monitor streaming replication lag, I use a combination of:


pg_current_xlog_location()
pg_last_xlog_replay_location()
pg_last_xact_replay_timestamp()


The first two functions are used to determine if there is any lag between the master and standby. If there is some lag, then I determine it with:

select now() - pg_last_xact_replay_timestamp();


Mostly it returns reasonable amounts -- seconds to minutes of lag.
However occasionally, that statement will return unlikely, large values. Several days of lag.

We don't have any transactions in our system that run for that long, not even close.

Can anyone suggest what is going on here?
Answering this from the future - when I have seen this, it means there have not been any writes to the primary (upstream) database in a while.
If there are no recent transactions on the primary, there are no recent transactions to replay on the follower, so pg_last_xact_replay_timestamp() will just report the time of the last write to primary.