Re: BUG #14808: V10-beta4, backend abort
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>, phb07@apra.asso.fr, Andrew Gierth <rhodiumtoad@postgresql.org>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>,
Kevin Grittner <kgrittn@gmail.com>
Date: 2017-09-12T01:22:36Z
Lists: pgsql-bugs
On Tue, Sep 12, 2017 at 12:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > OTOH, looking at the text of > the spec, I think it's darn hard to justify the behavior shown above. Yeah. I assume we always fired statement triggers for each separate instance of the same table mentioned in a wCTE since they were invented. I just confirmed that that is the case in 9.6. That may not have been in the spirit of the spec, but it's hard to say because the spec doesn't have wCTEs IIUC and it mattered less because they didn't receive any data. Now that they can optionally see data resulting from modifications, it seems pretty hard to use this feature to build anything that consumes the transition data and has to be reliable (matview state, replication-like systems etc) if we make any choice other than (1) each instance of a given table fires a statement trigger separately and sees only the rows it touched, or (2) the statement trigger is fired once for all instances of a table, and sees all the transition tuples. Based on the SQL spec excerpts you've highlighted, I suppose it seems likely that if the spec had wCTEs it would expect them to work like (2). -- Thomas Munro http://www.enterprisedb.com
Commits
-
Fix SQL-spec incompatibilities in new transition table feature.
- 54d4d0ff6cd4 10.0 landed
- 0f79440fb0b4 11.0 landed
-
Quick-hack fix for foreign key cascade vs triggers with transition tables.
- 5c11717185bc 10.0 landed
- 3c435952176a 11.0 landed
-
Fix transition tables for ON CONFLICT.
- 8c55244ae379 10.0 cited
-
Fix transition tables for wCTEs.
- c46c0e5202e8 10.0 cited
-
Repair problems occurring when multiple RI updates have to be done to the same
- 9cb84097623e 8.3.0 cited