Proposal: Expose oldest xmin as SQL function for monitoring

Поиск
Список
Период
Сортировка
От James Coleman
Тема Proposal: Expose oldest xmin as SQL function for monitoring
Дата
Msg-id CAAaqYe9Dy9sicKg3xzCQUMK3VLdEP39g9nMGZheqtFYfNiO5Bg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Proposal: Expose oldest xmin as SQL function for monitoring
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: snapshot too old issues, first around wraparound and then more.
Следующее
От: David Steele
Дата:
Сообщение: Re: backup manifests