On Thu, Sep 14, 2017 at 10:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> Aside from the RI case, the other user visible change in behaviour
>> will be for statements that update the same table via multiple
>> ModifyTable nodes (wCTEs). Our regression test has:
>
>> with wcte as (insert into table1 values (42))
>> insert into table2 values ('hello world');
>
>> ... which demonstrates the fix for the original complaint that table1
>> and table2 earlier tried to use the same transition table (and
>> crashed).
>
> 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. I
suppose it was by copying that coding that Kevin finished up with the
initial bug that wCTEs mix stuff from different wCTEs and it all blows
up, because it has no similar sequencing trick: triggers with
transition tables were seeing all of them, and they weren't even
guaranteed to be of the right type.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs