Possible wrong information about replication lag

[amradk]

As I found pgdoctor using next query to determine replication lag:
"SELECT extract('epoch' from " \ "(now()-pg_last_xact_replay_timestamp())) " \ "AS replication_lag;"
This query may return incorrect value in case when there are no updates for database for some period. So if last update (delete or insert) was, for example, a hour ago this query will return value of replication_lag eq to 1 hour but it is not true! There are just no new date, so actually no replication lag.

[marcoalmeida]

This is by design and has been discussed before in other places. Check, for example, this thread on pgsql-admin:
https://www.postgresql.org/message-id/CADKbJJWz9M0swPT3oqe8f9+tfD4-F54uE6Xtkh4nERpVsQnjnw@mail.gmail.com

The main reason pgDoctor relies on the time difference is that on a typical production system where you are leveraging streaming replicas for offloading SELECT traffic, the load is probably high enough that there are never long periods without any INSERT/UPDATE/DELETE commands.
This has indeed served us well at Thumbtack over the last few years.

Would you propose any other approach we could possibly implement alongside this one?