At Mon, 15 Aug 2022 11:16:56 +0900, Masahiko Sawada <sawada.m...@gmail.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....@gmail.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....@gmail.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
