Breakage in trigger.c - Mailing list pgsql-hackers

From Tom Lane
Subject Breakage in trigger.c
Date
Msg-id 19276.1094507729@sss.pgh.pa.us
Whole thread Raw
Responses Re: Breakage in trigger.c
Re: Breakage in trigger.c
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: SetQuerySnapshot redesign: yet another try
Next
From: Alvaro Herrera
Date:
Subject: Re: Breakage in trigger.c