On Fri, Sep 15, 2017 at 4:55 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 12 September 2017 at 12:39, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> On 12 September 2017 at 11:57, Dilip Kumar <dilipbal...@gmail.com> wrote: >>> On Tue, Sep 12, 2017 at 11:15 AM, Amit Khandekar <amitdkhan...@gmail.com> >>> wrote: >>> > I found out that, in case when there is a DELETE statement trigger > using transition tables, it's not only an issue of redundancy; it's a > correctness issue. Since for transition tables both DELETE and UPDATE > use the same old row tuplestore for capturing OLD table, that table > gets duplicate rows: one from ExecARDeleteTriggers() and another from > ExecARUpdateTriggers(). In presence of INSERT statement trigger using > transition tables, both INSERT and UPDATE events have separate > tuplestore, so duplicate rows don't show up in the UPDATE NEW table. > But, nevertheless, we need to prevent NEW rows to be collected in the > INSERT event tuplestore, and capture the NEW rows only in the UPDATE > event tuplestore. > > In the attached patch, we first call ExecARUpdateTriggers(), and while > doing that, we first save the info that a NEW row is already captured > (mtstate->mt_transition_capture->tcs_update_old_table == true). If it > captured, we pass NULL transition_capture pointer to > ExecARDeleteTriggers() (and ExecARInsertTriggers) so that it does not > again capture an extra row. > > Modified a testcase in update.sql by including DELETE statement > trigger that uses transition tables.
Ok, this fix looks correct to me, I will review the latest patch. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
