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

Re: Nested Transactions, Abort All

From: Thomas Swan <tswan(at)idigx(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-02 18:37:46
Message-ID: 40E5AB7A.1080504@idigx.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera wrote:

>On Fri, Jul 02, 2004 at 01:14:25PM -0400, Merlin Moncure wrote:
>  
>
>>>If we change the syntax, say by using SUBCOMMIT/SUBABORT for
>>>subtransactions, then using a simple ABORT would abort the whole
>>>transaction tree.
>>>      
>>>
>>Question: with the new syntax, would issuing a BEGIN inside a already
>>started transaction result in an error?
>>    
>>
>
>Yes.
>
>  
>
>>My concern is about say, a pl/pgsql function that opened and closed a
>>transation.  This could result in different behaviors depending if
>>called from within a transaction, which is not true of the old syntax.  
>>
>>Then again, since a statement is always transactionally wrapped, would
>>it be required to always issue SUBBEGIN if issued from within a
>>function?  This would address my concern.
>>    
>>
>
>Yes, I was thinking about this because the current code behaves wrong if
>a BEGIN is issued and not inside a transaction block.  So we'd need to
>do something special in SPI -- not sure exactly what, but the effect
>would be that the function can't issue BEGIN at all and can only issue
>SUBBEGIN.
>
>  
>
Isn't this counterintuitive.   It seems that BEGIN and COMMIT/ABORT 
should be sufficient regardless of the level.  If you are inside a 
current transaction those commands start a new transaction inside of the 
current transaction level, just like pushing on and popping off elements 
on a stack.  

I'm not trying to be argumentative, but the notation seems orthogonal to 
the issue.

Some functions and procedures may not be called inside of transactions  
or subtransactions.    Having to start with a SUBBEGIN and 
SUBCOMMIT/SUBABORT is equally problematic if you don't know where you 
begin.   Taking the extreme everything should be a SUBBEGIN and a 
SUBCOMMIT/SUBABORT so why have BEGIN and END?

Unless you have some way to tell (by query) the state you are in is a 
subtransaction and how many levels you are deep into the nested 
transaction, deciding whether to use SUBBEGIN and SUBCOMMIT/SUBABORT vs 
the traditional BEGIN COMMIT/ABORT becomes nondeterministic.



In response to

Responses

pgsql-hackers by date

Next:From: Mike MascariDate: 2004-07-02 19:33:34
Subject: Re: Nested Transactions, Abort All
Previous:From: Jochem van DietenDate: 2004-07-02 17:50:08
Subject: Re: Adding column comment to information_schema.columns

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