Re: Add sub-transaction overflow status in pg_stat_activity

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Add sub-transaction overflow status in pg_stat_activity
Дата
Msg-id CA+TgmoZLUGLkE1E8OyF9au03z-CiCwUFR=FTJ7b=57kk_LsoKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add sub-transaction overflow status in pg_stat_activity  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Add sub-transaction overflow status in pg_stat_activity  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum
Следующее
От: Frédéric Yhuel
Дата:
Сообщение: Re: Allow parallel plan for referential integrity checks?