Alvaro Herrera wrote:
> On Sat, Jul 10, 2004 at 09:46:56AM +1200, Oliver Jowett wrote:
>
>>Alvaro Herrera wrote:
>>
>>
>>>We can't actually release anything (commit the subtransactions), because
>>>they may be savepoints established after that point, and they are
>>>logically "inside" the previously established ones. At RELEASE we can't
>>>really release -- we just lose the name and thus the opportunity to
>>>rollback to it.
>>
>>The 2003 draft claims that RELEASE SAVEPOINT invalidates savepoints
>>subsequent to the RELEASE:
(that should read "subsequent to the released savepoint")
> In our case, invalidating a savepoint does not mean we can release its
> resources. We can only do that if it's the latest defined savepoint.
I don't understand why this is true if the invalidation comes from a
RELEASE statement. I understand the problems with savepoint name reuse
invalidating an earlier savepoint -- we do have to keep the earlier txn
open in that case.
Say I have:
SAVEPOINT s1 -- work 1 SAVEPOINT s2 -- work 2 RELEASE SAVEPOINT s1 -- Invalidates s1 and s2
Can't we translate that to:
begin subtransaction s1 -- work 1 begin subtransaction s2 -- work 2 commit subtransaction s1 -- and
implicitlys2
We don't need to keep subtransaction s2 open -- we will never need to
roll it back as the RELEASE of s1 invalidates it.
What am I missing?
-O
