Re: Add sub-transaction overflow status in pg_stat_activity
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Julien Rouhaud <rjuju123@gmail.com>, "Bossart, Nathan" <bossartn@amazon.com>, Dilip Kumar <dilipbalaut@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-11-14T16:04:14Z
Lists: 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
Commits
-
Fix comment that was missing a word.
- eb60eb08a95e 16.0 landed
-
Expose some information about backend subxact status.
- 10ea0f924a27 16.0 landed