Re: BUG #5798: Some weird error with pl/pgsql procedure

I wrote:
> [ theory about cause of bug #5798 ]

Attached is a proposed patch against HEAD to fix this problem. It's a
bit hard to *prove* that it fixes the problem, since there's no easy way
to force the collision of palloc addresses. But I think it will.

The patch changes the signature of ExecBRUpdateTriggers so that it takes
and returns a TupleTableSlot instead of a HeapTuple. This essentially
just moves the troublesome code (the "if (newtuple != tuple)" block)
from ExecUpdate to the bottom of ExecBRUpdateTriggers. It solves the
problem because in the case where ExecBRUpdateTriggers clobbers the
contents of the junkfilter's output slot, it can immediately update the
tuple pointer that will later be compared to see if the trigger(s)
replaced the tuple.

I chose to change ExecBRInsertTriggers, ExecIRInsertTriggers, and
ExecIRUpdateTriggers to also take and return TupleTableSlots. These
functions don't have a bug AFAICS, but it seems better that they all
retain similar APIs.

I'm not sure whether to back-patch all four changes or limit the patch
to changing ExecBRUpdateTriggers in the back branches. Any thoughts
about that?

regards, tom lane