Re: suboverflowed subtransactions concurrency performance optimize - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: suboverflowed subtransactions concurrency performance optimize
Date
Msg-id CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com
Whole thread Raw
In response to Re: suboverflowed subtransactions concurrency performance optimize  (Michael Paquier <michael@paquier.xyz>)
Responses Re: suboverflowed subtransactions concurrency performance optimize
List pgsql-hackers
On Thu, May 26, 2022 at 12:53 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, May 24, 2022 at 04:52:50PM -0700, Andres Freund wrote:
>
> > 2) xid wraparound. There's nothing forcing SubTransGetTopmostTransaction() to
> >    be called regularly, so even if a backend isn't idle, the cache could just
> >    get more and more outdated until hitting wraparound
>
> Hence, you mean that the non-regularity of the call makes it more
> exposed to an inconsistent result after a wraparound?
>

Won't in theory the similar cache in transam.c is also prone to
similar behavior?

Anyway, how about if we clear this cache for subtrans whenever
TransactionXmin is advanced and cachedFetchSubXid precedes it? The
comments atop SubTransGetTopmostTransaction seem to state that we
don't care about the exact topmost parent when the intermediate one
precedes TransactionXmin. I think it should preserve the optimization
because anyway for such cases there is a fast path in
SubTransGetTopmostTransaction.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Support logical replication of DDLs
Next
From: Etsuro Fujita
Date:
Subject: Re: doc: CREATE FOREIGN TABLE .. PARTITION OF .. DEFAULT