Re: Segmentation fault during update inside ExecBRUpdateTriggers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Right, this happens on REL_11_STABLE but not on master (which rewrote
> the relevant code quite a bit in the "slotification" project).

We should probably trace back why it doesn't happen before v11.
I have a vague memory of having touched this code a year or two
back, so likely this is my fault, but I wonder why it doesn't
fail before.

> In a very quick test, the following change fixes the problem and
> passes regression tests, but I'm not sure if it's the right fix.

> - if (oldtuple != newtuple && oldtuple != slottuple)
> + if (oldtuple != newtuple && oldtuple != slottuple &&
> oldtuple != trigtuple)

My thoughts were headed in the same direction. It looks like the
issue is that the first trigger returns OLD, ie "trigtuple",
which gets assigned to "newtuple", and then the second iteration
of the loop fails to deal with the aliasing.

[ thinks some more... ] Actually, I'm beginning to recall that
we made changes here because v11 plpgsql is capable of actually
returning "trigtuple" where before it would always have made a copy.
If that's accurate, then very likely the bug exists further back
but requires some other PL than plpgsql to manifest.

I'd be inclined to put a test case exercising this into all branches,
even ones not currently showing the bug, because it's clearly a
fragile area.

regards, tom lane