On Fri, Oct 14, 2022 at 3:38 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Mon, Oct 3, 2022 at 1:46 PM Michael Paquier <michael@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.
