Re: Nested xacts: looking for testers and review - Mailing list pgsql-hackers

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;-- 1begin; set constraints all immediate;end;-- 2
end;

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