Breakage in trigger.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Breakage in trigger.c
Date: 2004-09-06 21:55:29
Message-ID: 19276.1094507729@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I can't believe that the coding at trigger.c line 2010 ff is correct:

/*
* Skip executing cancelled events, and events done by
* transactions that are not aborted.
*/
if (!(event->dte_event & TRIGGER_DEFERRED_CANCELED) ||
(event->dte_event & TRIGGER_DEFERRED_DONE &&
TransactionIdIsValid(event->dte_done_xid) &&
!TransactionIdDidAbort(event->dte_done_xid)))
{

Surely the sense of this is backwards, and it should be

if (!(event->dte_event & TRIGGER_DEFERRED_CANCELED) &&
!(event->dte_event & TRIGGER_DEFERRED_DONE &&
TransactionIdIsValid(event->dte_done_xid) &&
!TransactionIdDidAbort(event->dte_done_xid)))
{

AFAICT we don't actually use TRIGGER_DEFERRED_CANCELED, so the existing
coding never "skips" at all here, which makes it just a performance loss
rather than visible misbehavior.

I'm also concerned about the fact that the per-item states have
dti_done_xid values distinct from the whole-event value. It's
not obvious that a rollback of the subxact that did one item implies
a rollback of the subxact that last marked the event as scanned.
Can anyone offer a proof that that's OK? If it is OK, is it really
necessary to have per-item dti_done_xid at all?

Finally, surely the "Mark the event done" case should advance
prev_event? As-is the code is capable of messing up the list links.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2004-09-07 00:15:54 Re: Breakage in trigger.c
Previous Message Tom Lane 2004-09-06 21:15:13 SetQuerySnapshot redesign: yet another try