On Sat, Oct 15, 2022 at 4:58 PM Amit Kapila <amit.kapila16@gmail.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.
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
*/
RunningTransactions
GetRunningTransactionData(void)
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.
if (xlrec->subxid_overflow)
{
/*
* Server doesn't include any subtransactions if any transaction has
* overflowed its cached subtransactions.
*/
Assert(xlrec->subxcnt == 0)
appendStringInfoString(buf, "; subxid overflowed");
}
else 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]);
}
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.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
