Re: Race condition in TransactionIdIsInProgress - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Race condition in TransactionIdIsInProgress
Date
Msg-id CANbhV-GA0zLg_tFz=tjwSGxNXz9FVV9704vKmt+odbBQiwFCVw@mail.gmail.com
Whole thread Raw
In response to Re: Race condition in TransactionIdIsInProgress  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses Re: Race condition in TransactionIdIsInProgress
List pgsql-hackers
On Fri, 11 Feb 2022 at 08:48, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
>
> On Fri, 11 Feb 2022 at 06:11, Andres Freund <andres@anarazel.de> wrote:
>
> > Looks lik syncrep will make this a lot worse, because it can drastically
> > increase the window between the TransactionIdCommitTree() and
> > ProcArrayEndTransaction() due to the SyncRepWaitForLSN() inbetween.  But at
> > least it might make it easier to write tests exercising this scenario...
>
> Agreed
>
> TransactionIdIsKnownCompleted(xid) is only broken because the single
> item cache is set too early in some cases. The single item cache is
> important for performance, so we just need to be more careful about
> setting the cache.

Something like this... fix_cachedFetchXid.v1.patch prevents the cache
being set, but this fails! Not worked out why, yet.

just_remove_TransactionIdIsKnownCompleted_call.v1.patch
just removes the known offending call, passes make check, but IMHO
leaves the same error just as likely by other callers.

-- 
Simon Riggs                http://www.EnterpriseDB.com/

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: Identify missing publications from publisher while create/alter subscription.
Next
From: Robert Haas
Date:
Subject: Re: refactoring basebackup.c