Re: Improve description of XLOG_RUNNING_XACTS

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, amit(dot)kapila16(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-14 10:08:20
Message-ID: CALj2ACXyh=0TjAxZC5tv5fRMnqYGEdvXPheUzwF5=qM=UdWLHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 3, 2022 at 1:46 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Fri, Sep 16, 2022 at 10:55:53AM +0900, Kyotaro Horiguchi wrote:
> > Putting an arbitrary upper-bound on the number of subxids to print
> > might work? I'm not sure how we can determine the upper-bound, though.
>
> You could hardcode it so as it does not blow up the whole view, say
> 20~30. Anyway, I agree with the concern raised upthread about the
> amount of extra data this would add to the output, so having at least
> the number of subxids would be better than the existing state of
> things telling only if the list of overflowed. So let's stick to
> that.

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. This can blow-up the output.

Hard-limiting the number of subxids isn't a good idea because the
whole purpose of it is gone.

As Amit said upthread, we can't really link subtxns with the
corresponding txns by looking at the output of the pg_waldump. And I
understand that having the subxid info helped Mashaiko-san debug an
issue. Wouldn't it be better to have a SQL-callable function that can
return txn and all its subxid information? I'm not sure if it's useful
or worth at all because the contents are so dynamic. I'm not sure if
we have one already or if it's possible to have one such function.

> Here is another idea for the list of subxids: show the full list of
> subxids only when using --xid. We could always introduce an extra
> switch, but that does not seem worth the extra workload here.

This seems interesting, but I agree that the extra code isn't worth it.

FWIW, I quickly looked at few other resource managers XXXX_desc
functions to find if they output all the record's info:

xlog_desc - doesn't show restart point timestamp for xl_restore_point
record type and
logicalmsg_desc - doesn't show the database id that generated the record
clog_desc - doesn't show oldest xact db of xl_clog_truncate record
and there may be more.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-10-14 11:19:01 Re: Fix error message for MERGE foreign tables
Previous Message houzj.fnst@fujitsu.com 2022-10-14 09:29:32 RE: Perform streaming logical transactions by background workers and parallel apply