Re: Nested transactions: deferred triggers

On Wed, Jun 11, 2003 at 10:33:07PM -0400, Tom Lane wrote:

> My thought would be that TransactionGetDeferredTriggers() ought to be
> called in one place that then passes the list pointer to the other
> subroutines. I haven't looked at the code in detail to see how this
> fits in ... but I don't like the notion of all these little functions
> independently fetching a pointer from some nontrivial function. That
> opens you up to interesting problems if different functions manage to
> fetch different results.

Well, I can see it getting into serious trouble if something weird
happens. However, I don't know a better way to do this. Code snippets
follow.

typedef struct TransactionSpecialData
{
void *deferredTriggers;
/* some other things... */
} TransactionSpecialData;

typedef struct TransactionStateData
{
TransactionId transactionIdData;
...
/* the usual, and the "Special pointer" : */
TransactionSpecial special;
} TransactionStateData;

The TransactionSpecial is initialized on StartSubTransaction, which is
analogous to StartTransaction but is, of course, only called when a
subtransaction starts. If there's inconsistency in the management of
this, I don't think we have much way out but elog(PANIC) and such. I
don't have checks in place for this though.

When the (sub)transaction starts, DeferredTriggersBeginXact() is called
which does the same as in the posted patch plus a call to
TransactionSetDeferredTriggerQueue(). After that, the routines in
backend/commands/trigger.c just call
TransactionGetDeferredTriggerQueue() to get the current queue for
processing.

This routine is defined simply as:
void *
TransactionGetDeferredTriggerQueue(void)
{
TransactionState s = CurrentTransactionState;
return s->special->deferredTriggers;
}

and the setter is just the trivial opposite.

If there's a better way to do this I'll gladly rewrite this code. I
think the complexity of the mechanism I have in place is very close to
the minimum. One possible idea is to have a global variable that is
changed at subtransaction start... however I think handling that is more
complicated because we need to append some things on subtrans commit but
forget them on subtrans abort, so it's not that trivial.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)