Re: BUG #14808: V10-beta4, backend abort
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, phb07 <phb07@apra.asso.fr>,
Thomas Munro <thomas.munro@enterprisedb.com>,
Andrew Gierth <rhodiumtoad@postgresql.org>,
PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-09-11T19:24:40Z
Lists: pgsql-bugs
Robert Haas <robertmhaas@gmail.com> writes: > On Sat, Sep 9, 2017 at 1:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> My first instinct is to get rid of DestroyTransitionCaptureState >> altogether, on the grounds that the TransitionCaptureState will >> go away at transaction cleanup and we can't really get rid of it >> any sooner than that. > End of transaction, or end of query? I'm not sure what happens when > triggers are deferred, but I think there are a lot of cases when we > want to throw away the tuplestore immediately, not hold on to it for > the rest of the transaction. As things stand, it's end of subtransaction, because the TCSes are allocated in CurTransactionContext. See the argument in MakeTransitionCaptureState. And yes, this is inefficient. The quick-hack patch I committed yesterday only pays the price if you have RI triggers cascading changes into a table that also has triggers-with-transition-tables, but I can certainly believe that it could get expensive in such a case. The fix proposal discussed downthread should fix the inefficiency as well as the spec compliance problem. But personally I'm far more worried about the latter. regards, tom lane
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