On Mon, Nov 14, 2022 at 10:09:57AM -0500, Robert Haas wrote: > On Mon, Mar 21, 2022 at 7:45 PM Andres Freund <and...@anarazel.de> wrote: > > > It feels to me like far too much effort is being invested in fundamentally > > > the wrong direction here. If the subxact overflow business is causing > > > real-world performance problems, let's find a way to fix that, not put > > > effort into monitoring tools that do little to actually alleviate anyone's > > > pain. > > > > There seems to be some agreement on this (I certainly do agree). Thus it > > seems > > we should mark the CF entry as rejected? > > I don't think I agree with this outcome, for two reasons. > > 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. > If and when it happens that a field like backend_xmin or the new ones > proposed here are no longer relevant, we can just remove them from the > monitoring views. Yeah, that's a backward compatibility break, and > there's some pain associated with that. But we have demonstrated that > we are perfectly willing to incur the pain associated with adding new > columns when there is new and valuable information to display, and > that is equally a compatibility break, in the sense that it has about > the same chance of making pg_upgrade fail. 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? -- Justin
