Re: Improve description of XLOG_RUNNING_XACTS

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sawada(dot)mshk(at)gmail(dot)com, ashutosh(dot)bapat(at)enterprisedb(dot)com, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Improve description of XLOG_RUNNING_XACTS
Date: 2022-10-16 07:02:56
Message-ID: CALj2ACWkiiOtJVVQpX-ceSheUboP4pY_DeU8qrDauYZWcka4Fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

* 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

Attachment Content-Type Size
v3-0001-Improve-description-of-XLOG_RUNNING_XACTS.patch application/octet-stream 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-10-16 07:35:54 Re: archive modules
Previous Message Andres Freund 2022-10-16 05:34:43 Re: macos ventura SDK spews warnings