Proposal: Expose oldest xmin as SQL function for monitoring - Mailing list pgsql-hackers

From James Coleman
Subject Proposal: Expose oldest xmin as SQL function for monitoring
Date
Msg-id CAAaqYe9Dy9sicKg3xzCQUMK3VLdEP39g9nMGZheqtFYfNiO5Bg@mail.gmail.com
Whole thread Raw
Responses Re: Proposal: Expose oldest xmin as SQL function for monitoring  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Currently there's no good way that I'm aware of for monitoring
software to check what the xmin horizon is being blocked at. You can
check pg_stat_replication and pg_replication_slots and
txid_snapshot_xmin(txid_current_snapshot()) and so on, but that list
can grow, and it means monitoring setups need to update any time any
new feature might hold another snapshot and expose it in a different
way.

To my knowledge the current oldest xmin (GetOldestXmin() if I'm not
mistaken) isn't exposed directly in any view or function by Postgres.

Am I missing anything in the above description? And if not, would
there be any reason why we would want to avoid exposing that
information? And if not, then would exposing it as a function be
acceptable?

Thanks,
James



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: snapshot too old issues, first around wraparound and then more.
Next
From: David Steele
Date:
Subject: Re: backup manifests