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+TgmobfU87ewCj-n3kDWfYnS9yteFw7tWRsq-7a+Pktty5unA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add sub-transaction overflow status in pg_stat_activity  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Add sub-transaction overflow status in pg_stat_activity  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
On Mon, Nov 14, 2022 at 10:57 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > First, we're just talking about an extra couple of columns in
> > pg_stat_activity here, which does not seem like a heavy price to pay.
>
> The most recent patch adds a separate function rather than adding more
> columns to pg_stat_activity.  I think the complaint about making that
> view wider for infrequently-used columns is entirely valid.

I guess that's OK. I don't particularly favor that approach here but I
can live with it. I agree that too-wide views are annoying, but as far
as pg_stat_activity goes, that ship has pretty much sailed already,
and the same is true for a lot of other views. Inventing a one-off
solution for this particular case doesn't seem particularly warranted
to me but, again, I can live with it.

> Why would pg_upgrade fail due to new/removed columns in
> pg_stat_activity?  Do you mean if a user creates a view on top of it?

Yes, that is a thing that some people do, and I think it is the most
likely way for any changes to the view definition to cause
compatibility problems. I could be wrong, though.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: when the startup process doesn't (logging startup delays)
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Add sub-transaction overflow status in pg_stat_activity