Horton

Re: suboverflowed subtransactions concurrency performance optimize

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, Julien Rouhaud <rjuju123@gmail.com>, Simon Riggs <simon.riggs@enterprisedb.com>, Andrey Borodin <x4mmm@yandex-team.ru>, Pengchengliu <pengchengliu@tju.edu.cn>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-05-27T10:14:39Z
Lists: 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.

Commits

  1. Revert "Add single-item cache when looking at topmost XID of a subtrans XID"

  2. Add single-item cache when looking at topmost XID of a subtrans XID

  3. Fix handling of partitioned index in RelationGetNumberOfBlocksInFork()