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
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 |