| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: TransactionIdIsInProgress() cache |
| Date: | 2008-03-11 14:15:45 |
| Message-ID: | 20080311141545.GE9116@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Heikki Linnakangas wrote:
> 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.
Ah, right -- I knew there was a reason for the other coding, I just
didn't remember what it was and based my transformation purely on the
snippet you posted.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-03-11 14:41:57 | Re: [PATCHES] Fix for large file support (nonsegment mode support) |
| Previous Message | Heikki Linnakangas | 2008-03-11 14:03:08 | Re: [PERFORM] Very slow (2 tuples/second) sequentialscan after bulk insert; speed returns to ~500 tuples/second aftercommit |