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

From Simon Riggs
Subject Re: Race condition in TransactionIdIsInProgress
Date
Msg-id CANbhV-GGckHbn6WwAf84kSERomPbUr0ghmu9gRZWA8784uhfAQ@mail.gmail.com
Whole thread Raw
In response to Re: Race condition in TransactionIdIsInProgress  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Race condition in TransactionIdIsInProgress
List pgsql-hackers
On Sat, 25 Jun 2022 at 10:18, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 24/06/2022 04:43, Andres Freund wrote:
> > On 2022-06-23 22:03:27 +0300, Heikki Linnakangas wrote:
> >> In summary, I think we should:
> >> - commit and backpatch Simon's
> >> just_remove_TransactionIdIsKnownCompleted_call.v1.patch
> >> - fix pg_xact_status() to check TransactionIdIsInProgress()
> >> - in v15, remove TransationIdIsKnownCompleted function altogether
> >>
> >> I'll try to get around to that in the next few days, unless someone beats me
> >> to it.
> >
> > Makes sense.
>
> This is what I came up with for master. One difference from Simon's
> original patch is that I decided to not expose the
> TransactionIdIsKnownNotInProgress(), as there are no other callers of it
> in core, and it doesn't seem useful to extensions. I inlined it into the
> caller instead.

Looks good, thanks.

> BTW, should we worry about XID wraparound with the cache? Could you have
> a backend sit idle for 2^32 transactions, without making any
> TransactionIdIsKnownNotInProgress() calls? That's not new with this
> patch, though, it could happen with the single-item cache in transam.c, too.

Yes, as a separate patch only in PG15+, imho.

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Race condition in TransactionIdIsInProgress
Next
From: Dean Rasheed
Date:
Subject: Re: Core dump in range_table_mutator()