Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group