Re: Add sub-transaction overflow status in pg_stat_activity - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Add sub-transaction overflow status in pg_stat_activity
Date
Msg-id 20221114174748.w6ob2a3lfhlayxlc@awork3.anarazel.de
Whole thread Raw
In response to Re: Add sub-transaction overflow status in pg_stat_activity  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add sub-transaction overflow status in pg_stat_activity
List pgsql-hackers
Hi,

On 2022-11-14 12:29:58 -0500, Tom Lane wrote:
> I'd vote for just overflowed true/false.  Why do people need to know
> the exact number of subtransactions?  (If there is a use-case, that
> would definitely be material for an auxiliary function instead of a
> view column.)

I'd go the other way. It's pretty unimportant whether it overflowed, it's
important how many subtxns there are. The cases where overflowing causes real
problems are when there's many thousand subtxns - which one can't judge just
from suboverflowed alone. Nor can monitoring a boolean tell you whether you're
creeping closer to the danger zone.

Monitoring the number also has the advantage that we'd not embed an
implementation detail ("suboverflowed") in a view. The number of
subtransactions is far less prone to changing than the way we implement
subtransactions in the procarray.

But TBH, to me this still is something that'd be better addressed with a
tracepoint.

I don't buy the argument that the ship of pg_stat_activity width has entirely
sailed. A session still fits onto a reasonably sized terminal in \x output -
but not much longer.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: HOT chain validation in verify_heapam()
Next
From: Andres Freund
Date:
Subject: Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock