On Fri, Oct 14, 2022 at 3:38 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Mon, Oct 3, 2022 at 1:46 PM Michael Paquier <mich...@paquier.xyz> wrote: > > > > On Fri, Sep 16, 2022 at 10:55:53AM +0900, Kyotaro Horiguchi wrote: > > > Putting an arbitrary upper-bound on the number of subxids to print > > > might work? I'm not sure how we can determine the upper-bound, though. > > > > You could hardcode it so as it does not blow up the whole view, say > > 20~30. Anyway, I agree with the concern raised upthread about the > > amount of extra data this would add to the output, so having at least > > the number of subxids would be better than the existing state of > > things telling only if the list of overflowed. So let's stick to > > that. > > I spent some time today reading this. As others said upthread, the > output can be more verbose if all the backends are running max > subtransactions or subtransactions overflow occurred in all the > backends. >
As far as I can understand, this contains subtransactions only when they didn't overflow. The latest information provided by Sawada-San for similar records (XLOG_STANDBY_LOCK and XLOG_INVALIDATIONS) made me think that maybe we are just over-worried about the worst case. > This can blow-up the output. > If we get some reports like that, then we can probably use Michael's idea of displaying additional information with a separate flag. > Hard-limiting the number of subxids isn't a good idea because the > whole purpose of it is gone. > Agreed. -- With Regards, Amit Kapila.
