Re: BUG #14808: V10-beta4, backend abort

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Thu, Sep 14, 2017 at 10:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, as I'm digging around in trigger.c, I can't help noticing that
>> it provides a single "fdw_tuplestore" per trigger query level (a/k/a
>> trigger execution context). I've not tried to test this, but it
>> sure looks like a wCTE like your example above, directed at two
>> separate foreign tables with triggers, would fail for exactly the
>> same reason. That'd be a bug of pretty long standing.

> I had the impression that that fdw_tuplestore was doing something a
> bit sneaky that actually works out OK: tuples get enqueued and later
> dequeued in exactly the same sequence as the after row trigger events
> that need them, so even though it seems to violate at least the POLA
> if not the spirit of tuplestores by storing tuples of potentially
> different types in one tuplestore, nothing bad should happen.

Oh? Now my fear level is up to 11, because it is completely trivial to
cause triggers to fire in a different order than they were enqueued.
All you need is a mix of deferrable and nondeferrable triggers.

In fact, it also seems entirely broken that a per-query-level tuplestore
is being used at all, because deferrable triggers might not get fired
until some outer query level.

[ Pokes around... ] Hm, looks like we get around that by forbidding
constraint triggers on foreign tables, but I don't see anything in the
CREATE TRIGGER man page saying that there's such a prohibition. And
there's certainly no comments in the source code explaining this rickety
set of requirements :-(

regards, tom lane