-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible wrong information about replication lag #11
Comments
This is by design and has been discussed before in other places. Check, for example, this thread on pgsql-admin: 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. Would you propose any other approach we could possibly implement alongside this one? |
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.
The text was updated successfully, but these errors were encountered: