From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] V3: Idle in transaction cancellation |
Date: | 2010-11-02 21:52:17 |
Message-ID: | 1288734369-sup-3437@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Andres Freund's message of mar nov 02 18:36:19 -0300 2010:
> On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
> > Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > * You wont see an error if the next command after the IDLE in
> > > transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
> > > around that.
> > Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
> > couldn't you call a function to check for it in CommitTransaction
> > and PrepareTransaction?
> Sure, throwing an error somewhere wouldnt be that hard. But at the moment a
> COMMIT is always successfull (and just reporting a ROLLBACK in a failed txn).
> Doesn't seem to be something to changed lightly.
If the user calls COMMIT, it calls EndTransactionBlock, which ends up
calling AbortTransaction. Can't you do it at that point? (Says he who
hasn't looked at the patch at all)
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-11-02 21:59:15 | Re: [PATCH] V3: Idle in transaction cancellation |
Previous Message | Tom Lane | 2010-11-02 21:47:39 | Re: Hash support for arrays |