On 1/6/20 5:52 μ.μ., Keith Fiske wrote:
Thank you, seems like a nice write-up, I'll check this out.
On Mon, Jun 1, 2020 at 8:41 AM Achilleas Mantzios <achill@xxxxxxxxxxxxxxxxxxxxx> wrote:
Hello Julien
On 1/6/20 2:03 μ.μ., Julien Rouhaud wrote:
> On Mon, Jun 1, 2020 at 12:48 PM Achilleas Mantzios
> <achill@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> On 1/6/20 1:36 μ.μ., Julien Rouhaud wrote:
>>> On Mon, Jun 1, 2020 at 12:02 PM Achilleas Mantzios
>>> <achill@xxxxxxxxxxxxxxxxxxxxx> 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.
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
--
