Re: Add sub-transaction overflow status in pg_stat_activity

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Add sub-transaction overflow status in pg_stat_activity
Дата
Msg-id 20221114174748.w6ob2a3lfhlayxlc@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Add sub-transaction overflow status in pg_stat_activity  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add sub-transaction overflow status in pg_stat_activity
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: HOT chain validation in verify_heapam()
Следующее
От: Andres Freund
Дата:
Сообщение: Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock