Re: Improve description of XLOG_RUNNING_XACTS

At Mon, 15 Aug 2022 11:16:56 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in
> Sorry for the late reply.

No worries. Anyway I was in a long (as a Japanese:) vacation.

> On Thu, Jul 28, 2022 at 4:29 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > record is sound". Is it any trouble with assuming the both *can*
> > happen at once? If something's broken, it will be reflected in the
> > output.
>
> Fair point. We may not need to interpret the contents.

Yeah.

> On Thu, Jul 28, 2022 at 3:24 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> >
> > Another point is if the xid/subxid lists get long, I see it annoying
> > that the "overflowed" messages goes far away to the end of the long
> > line. Couldn't we rearrange the item order of the line as the follows?
> >
> > nextXid %u latestCompletedXid %u oldestRunningXid %u;[ subxid overflowed;][ %d xacts: %u %u ...;][ subxacts: %u %u ..]
> >
>
> I'm concerned that we have two information of subxact apart. Given
> that showing both individual subxacts and "overflow" is a bug, I think

Bug or every kind of breakage of the file. So if "overflow"ed, we
don't need to show a subxid there but I thought that there's no need
to change behavior in that case since it scarcely happens.

> we can output like:
>
> if (xlrec->subxcnt > 0)
> {
> appendStringInfo(buf, "; %d subxacts:", xlrec->subxcnt);
> for (i = 0; i < xlrec->subxcnt; i++)
> appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
> }
>
> if (xlrec->subxid_overflow)
> appendStringInfoString(buf, "; subxid overflowed");

Yea, it seems like what I proposed upthread. I'm fine with that since
it is an abonormal situation.

> Or we can output the "subxid overwlowed" first.

(I prefer this, as that doesn't change the output in the normal case
but the anormality will be easilly seen if happens.)

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center