Re: TransactionIdIsInProgress() cache - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: TransactionIdIsInProgress() cache
Date
Msg-id 47D6901B.7020408@enterprisedb.com
Whole thread Raw
In response to Re: TransactionIdIsInProgress() cache  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: TransactionIdIsInProgress() cache  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
Alvaro Herrera wrote:
> I didn't check whether your transformation is correct, but if so then it
> can be changed like this and save the extra XidDidCommit call:
>
>     xvac_committed = TransactionIdDidCommit(xvac);
>     if (xvac_committed)
>     {
>         /* committed */
>     }
>     else if (!TransactionIdIsInProgress(xvac))
>     {
>        if (xvac_committed)
>        {
>           /* committed */
>        }
>        else
>        {
>           /* aborted */
>        }
>     }
>     else
>     {
>         /* in-progress */
>     }

Nope, that's not good. Per comments in tqual.c, you have to call
TransactionIdIsInProgress *before* TransactionIdDidCommit, to avoid this
race condition:

1. Xact A inserts a record
2. Xact B does TransactionIdDidCommit, which retuns false because it's
still in progress
3. Xact B commits
4. Xact B does TransactionIdIsInProgress to see if A is still in
progress. It returns false. We conclude that A aborted, while it
actually committed.

My proposal was basically to add an extra TransactionIdDidCommit call
before the TransactionIdIsInProgress call, in the hope that it returns
true and we can skip the rest.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequentialscan after bulk insert; speed returns to ~500 tuples/second aftercommit