On Wed, Jun 09, 2004 at 11:32:08PM -0700, Stephan Szabo wrote:
> > Unfortunately, I've gotten it to fail, but I haven't looked in depth (I'm
> > at work, so I'm doing it during compilations and such.)
[...]
> Okay - I think I see what's going on here.
>
> It looks like deferredTriggerInvokeEvents is being run (immediate_only),
> but since deferredTriggers->events_imm is NULL it's using
> deferredTriggers->events as the start of the list to check, but this value
> isn't getting reset in DeferredTriggerEndSubXact in the case that the
> entire list was created in an aborted subtransaction.
Ok, thanks for the test and diagnostics; patch attached. I'll see if I
can find other situations like this.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No hay cielo posible sin hundir nuestras raíces
en la profundidad de la tierra" (Malucha Pinto)
diff -u 10bgwriter/src/backend/commands/trigger.c
13commitOpt/src/backend/commands/trigger.c
--- 10bgwriter/src/backend/commands/trigger.c 2004-06-03 19:26:35.000000000 -0400
+++ 13commitOpt/src/backend/commands/trigger.c 2004-06-10 16:33:27.000000000 -0400
@@ -2278,9 +2278,11 @@
deferredTriggers->imm_stack[deferredTriggers->numpushed];
/*
- * Make sure the last element is last.
+ * Cleanup the head and the tail of the list.
*/
- if (deferredTriggers->tail_thisxact != NULL)
+ if (deferredTriggers->tail_thisxact == NULL)
+ deferredTriggers->events = NULL;
+ else
deferredTriggers->tail_thisxact->dte_next = NULL;
/*
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
