Re: Nested xacts: looking for testers and review

On Fri, 28 May 2004, Alvaro Herrera wrote:

> On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote:
>
> > On Wed, 26 May 2004, Alvaro Herrera wrote:
> >
> > > I have tested it and it passes all regression tests (including ones I
> > > added), plus some more tests I threw at it mainly for concurrency.
> > > Everything behaves as expected. At this time I'd like to have it
> > > reviewed by the critic eye of the committers, and tested by whoever
> > > would be using it.
> >
> > I unfortunately didn't really follow the discussions in the past (sorry :(
> > ), but are the transaction state modifying statements done in a
> > subtransaction supposed to live beyond subtransaction rollback?
>
> Hmm, I suppose not.

Actually, looking at it, for set transaction, the worse one is probably
isolation level because it can't be set after a query has been run and I'm
not entirely sure what the behavior should look like if you did something
like:

begin;
set transaction isolation level serializable;
begin;
set transaction isolation level read committed;
select * from a;
rollback;

At that point, is the transaction in serializable method and is the
snapshot set even though the select "never happened" and what does the
above really mean. Is it that the results of that first transactions are
out of serializability with the rest of the transaction?

Also related, although START TRANSACTION (specifying isolation level or
read onlyness as part) is currently defined to act as if set transaction
was used, it seems really odd that the settings would leak to the outer
translation even on a commit and that you can't specify isolation level -
even if it's the same level - if the outer transaction has done any
queries.

-----

BTW: For the deferred trigger stuff, I am guessing you haven't touched
that at all in the current patch?

I wonder if the following would work assuming that we want deferred
triggers to run at outer transaction end?

--
There's one trigger queue list and a stack of "last event before this
(sub)transaction started" pointers in and a current one similar to _imm is
the one for the current subtransaction. Scanning the list takes an extra
argument to say whether to consolidate the list or not (generally true
except for set state).

On outer transaction start,
NULL is set as the last event at start pointer

On subtransaction start,
The current last event at start pointer is added to the stack.
The last event at start pointer is set to _imm.
The _imm pointer should already be in the correct place

On subtransaction abort,
The queue is deallocated after the last event at start pointer and
the event in question its next pointer reset.
(if null, the list is entirely deallocated and the list is
set as null)
The _imm pointer is set to the last event at start pointer.
The last event at start pointer is popped from the stack.

On outer transaction abort,
Clear the queue.

On subtransaction commit,
The last event at start pointer is popped from the stack.

On outer transaction commit
Scan the deferred events.

On set state,
We call DeferredTriggerInvokeEvents with (true, false) rather than
relying on the statement end to do it (as true, true). This should set
the _imm pointer so that the end of statement won't scan anything anyway.

--
I think it might be possible to do the queue deallocation for
subtransaction abort with appropriate context work (each one gets a
context under its parent's and on abort it's removed and on commit it's
not until you reach the outermost?) but I haven't though about it enough.
And I think the non-removing events on set transaction could be fixed as
well.