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

From Robert Haas
Subject Re: Add sub-transaction overflow status in pg_stat_activity
Date
Msg-id CA+TgmoZLUGLkE1E8OyF9au03z-CiCwUFR=FTJ7b=57kk_LsoKw@mail.gmail.com
Whole thread Raw
In response to Re: Add sub-transaction overflow status in pg_stat_activity  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Add sub-transaction overflow status in pg_stat_activity  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Wed, Nov 30, 2022 at 11:01 AM Robert Haas <robertmhaas@gmail.com> wrote:
> That's not responsive to the need that I have. I need users to be able
> to figure out which backend(s) are overflowing their snapshots -- and
> perhaps how badly and how often --- not which backends are incurring
> an expense as a result. There may well be a use case for the latter
> thing but it's a different problem.

So ... I want to go ahead and commit Dilip's v4 patch, or something
very like it. Most people were initially supportive. Tom expressed
some opposition, but it sounds like that was mostly to the discussion
going on and on rather than the idea per se. Andres also expressed
some concerns, but I really think the problem he's worried about is
something slightly different and need not block this work. I note also
that the v4 patch is designed in such a way that it does not change
any view definitions, so the compatibility impact of committing it is
basically nil.

Any strenuous objections?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Frédéric Yhuel
Date:
Subject: Re: Allow parallel plan for referential integrity checks?