Re: [PATCH] V3: Idle in transaction cancellation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] V3: Idle in transaction cancellation
Date: 2010-11-02 22:52:40
Message-ID: 18476.1288738360@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On Tuesday 02 November 2010 22:59:15 Kevin Grittner wrote:
>>> Does anybody have any idea why COMMIT is allowed there? Seems
>>> pretty strange to me.

>> So that the "failed transaction" state can be cleared. The
>> transaction as a whole has failed, but you don't want the connection
>> to become useless.

> Well, allowing ROLLBACK is enought there, isnt it?

The client has no reason to think the transaction has failed, so what
it's going to send is COMMIT, not ROLLBACK. From the point of view of
the client, this should look like its COMMIT failed (or in general its
next command failed); not like there was some magic action-at-a-distance
on the state of its transaction.

Now you could argue that if you send COMMIT, and that fails, you should
have to send ROLLBACK to get to an idle state ... but that's not how
this ever worked before, and I don't think it's what the SQL standard
expects either. After a COMMIT, you're out of the transaction either
way.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ron Mayer 2010-11-03 04:22:40 Re: Hash support for arrays
Previous Message Dimitri Fontaine 2010-11-02 22:35:39 Re: create custom collation from case insensitive portuguese