On Mon, Nov 14, 2022 at 10:09:57AM -0500, Robert Haas wrote:
> On Mon, Mar 21, 2022 at 7:45 PM Andres Freund <andres@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
