Re: pg_stat_database.xact_commit + pg_stat_database.xact_rollback as a reliable metric for xid consumption ?

On Mon, Jun 1, 2020 at 8:41 AM Achilleas Mantzios <
achill(at)matrix(dot)gatewaynet(dot)com> wrote:

> Hello Julien
> On 1/6/20 2:03 μ.μ., Julien Rouhaud wrote:
> > On Mon, Jun 1, 2020 at 12:48 PM Achilleas Mantzios
> > <achill(at)matrix(dot)gatewaynet(dot)com> wrote:
> >> On 1/6/20 1:36 μ.μ., Julien Rouhaud wrote:
> >>> On Mon, Jun 1, 2020 at 12:02 PM Achilleas Mantzios
> >>> <achill(at)matrix(dot)gatewaynet(dot)com> wrote:
> >>> Because read only transaction usually don't consume an xid. So yes
> >>> pg_stat_database gives a more reasonable approximation of the real
> >>> number of transactions happening on the server.
> >> Thank you, so what would be the official way to monitor txid
> consumption (from a MVCC / Freezing admin POV)?
> > I'm not sure what you're really looking for.
> I've been as explicit as it gets. When ppl talk about vacuum freeze what
> they have in mind is xmin's and xmax's and the rate that xids grow and
> consume the 2^31 address space, so I find it strange
> that such a basic metric is not included in the core statistics collector.
> That's all.
> >
>
>
> --
> Achilleas Mantzios
> IT DEV Lead
> IT DEPT
> Dynacom Tankers Mgmt
>
>
>
>
I've done a writeup on effectively monitoring for xid
exhaustion/wraparound.

https://info.crunchydata.com/blog/managing-transaction-id-wraparound-in-postgresql

It is relatively simple to get the current xid state applying the age()
function to the pg_database catalog:

SELECT datname, age(datfrozenxid),
current_setting('autovacuum_freeze_max_age') FROM pg_database ORDER BY 2
DESC;

But the query in the linked blog post provides things in a more
user-friendly manner for monitoring purposes as simple percentages

--
Keith Fiske
Senior Database Engineer
Crunchy Data - http://crunchydata.com