Re: Improve description of XLOG_RUNNING_XACTS
От | Bharath Rupireddy |
---|---|
Тема | Re: Improve description of XLOG_RUNNING_XACTS |
Дата | |
Msg-id | CALj2ACWkiiOtJVVQpX-ceSheUboP4pY_DeU8qrDauYZWcka4Fw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve description of XLOG_RUNNING_XACTS (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: