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
Monitor backend_xmin #201
Comments
Can you elaborate here? I would rather add in |
The issue is similar to have a long running xact on a primary : we can't vacuum tuple. For example if you have a long running pg_dump on a standby server, this could degrade primary performance: index containing old tuple, HOT chain not cleaned etc I've seen write spikes on primary server when the xact is "freed", backends can prune record by themselves and when you have a big workload this could lead to production incident.
Hard to say, I mostly depends on your workload. Maybe 100K transactions is enough?
That's a good idea but I think we should also check backend_xmin in pg_stat_replication from primary. |
I agree that retained xmin horizon can be a real problem in some environment. Counter proposal: a new check, say oldest_xmin, that would give the oldest age(xmin) and oldest xmin for usual causes:
|
I'm volunteering to work on that. |
done |
Hi,
When you use hot_standby_feedback you may want to monitor xmin delta between primary and secondary to be alerted in case of long running transaction on secondary which cause bloat on primary.
Regards,
The text was updated successfully, but these errors were encountered: