| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Pengchengliu <pengchengliu(at)tju(dot)edu(dot)cn>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: suboverflowed subtransactions concurrency performance optimize |
| Date: | 2022-05-27 10:14:39 |
| Message-ID: | CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 26, 2022 at 12:53 PM Michael Paquier <michael(at)paquier(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2022-05-27 10:15:32 | Re: doc: CREATE FOREIGN TABLE .. PARTITION OF .. DEFAULT |
| Previous Message | houzj.fnst@fujitsu.com | 2022-05-27 09:07:46 | RE: Support logical replication of DDLs |