Re: Improve description of XLOG_RUNNING_XACTS

At Sun, 16 Oct 2022 12:32:56 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Sat, Oct 15, 2022 at 4:58 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > > 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.
>
> Agreed. I see the below comment, which means when
> xlrec->subxid_overflow is set to true, there will not be any
> subtransaction ids logged in the WAL record.

Since I categorized this tool as semi-debugging purpose so I'm fine
that sometimes very long lines are seen. In the first place it is
already seen in, for example, transaction commit records. They can be
30k characters long by many relfile locators, stats locators,
invalidations and snapshots, when 100 relations are dropped.

> If my above understanding is correct, having something like below does
> no harm, like Masahiko-san's one of the initial patches, no? I'm also
> fine with the way it is in the v3 patch.

Yeah, v3 works exactly the same way with the initial patch, except
when something bad happens in that record. So *I* thought that it's
rather better that the tool describes records as-is (even if only for
this record..:p) rather than how the broken records are recognized by
the recovery code.

> The v3 patch posted upthread LGTM and I marked it as RfC. I'm just
> reattaching the v3 patch posted upthread herewith so that the cfbot
> can test the right patch - https://commitfest.postgresql.org/40/3779/.
>
> > >
> > 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.
>
> Agreed.

Agreed, but maybe we need to recheck what should be hidden (or
abbreviated) in the concise (or terse?) mode.

--
Kyotaro Horiguchi
NTT Open Source Software Center