Re: TransactionIdIsInProgress() cache

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: TransactionIdIsInProgress() cache
Date: 2008-03-11 13:58:51
Message-ID: 47D6901B.7020408@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Larry Rosenman 2008-03-11 13:59:58 Re: [PATCHES] Fix for large file support (nonsegment mode support)
Previous Message Alvaro Herrera 2008-03-11 13:29:04 Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit