Re: Improve description of XLOG_RUNNING_XACTS

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