Re: Nested xacts: looking for testers and review

On Thu, 27 May 2004, Alvaro Herrera wrote:

> On Wed, May 26, 2004 at 04:35:52PM -0700, Stephan Szabo wrote:
>
> > On Wed, 26 May 2004, Alvaro Herrera wrote:
> >
> > > I'm missing one item: deferred triggers. The problem with this is that
> > > the deftrig queue is not implemented using normal Lists, so there's no
> > > efficient way to reassign to the parent when the subtransaction commits.
> > > Also I'm not sure what should happen to the "immediate" pointer --- a
> > > subtransaction should have it's own private copy, or it should inherit
> > > the parent's? Please whoever implemented this speak up (Stephan
> > > Szabo?), as I'm not sure of the semantics.
> >
> > The immediate pointer basically points at the end of the queue from the
> > last scanning of the trigger queue (since any "immediate" triggers from
> > before that would have been run at that time there's no reason to scan
> > from the beginning).
>
> Hmm. You assume correctly that a subtransaction has (or will have) a
> private queue. But we do not consider a subtransaction to be somewhat a
> separate entity -- the principle is that the transaction has to feel
> just like the BEGIN wasn't there. So
>
> BEGIN;
> UPDATE foo ...
> UPDATE bar ...
> COMMIT
>
> has to be exactly the same as
>
> BEGIN;
> BEGIN;
> UPDATE foo ...
> COMMIT;
> BEGIN;
> UPDATE bar ...
> COMMIT;
> COMMIT;
>
> Now, with that in mind: is it correct that the "immediate" pointer
> points to the beginning of the subtransaction's private deferred trigger
> queue, at subtransaction's start?

AFAIR you can set it to NULL because that means scan the entire list.

> Now, at subtransaction end, lets suppose I concatenate the list the
> original transaction had with the subtransaction's private list. What
> should the immediate pointer be?

I'd say pointing at the last item that was added to the queue.

> When is the immediate pointer advanced? I know it's "during scanning of
> the list", but when is this? At the end of each query?

At the point after triggers fire after a statement. It's the actual
scanning of the trigger queue to see what to run that changes it unless
I'm misremembering.

> > If one sets a constraint to immediate in a subtransaction, does/should
> > it cause the immediate check of pending events from its parent? And
> > does that revert when the transaction ends?
>
> Yes, I think it should fire all events, including the parent's. Good
> point; it means there has to be a way of getting the whole list, from
> the topmost transaction, in order :-(

Yeah... Right now we don't need to do something special because resetting
the immediate pointer basically does what we want (re-scan the entire set
looking for non-run things that are now immediate).

> I'm not sure what you mean by reverting though.

The state about whether a trigger is actually deferred or immediate. I
believe it basically works as:
begin;
set constraints all immediate;
-- here any deferrable constraints are treated as immediate
end;
begin;
-- here any deferrable constraints are in their default state
end;

So, if you have
begin;
-- 1
begin;
set constraints all immediate;
end;
-- 2
end;

Do 1 and 2 see the same constraint checking mode or is 2 at immediate?