Re: UPDATE of partition key

On Fri, Sep 15, 2017 at 4:55 PM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> On 12 September 2017 at 12:39, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
>> On 12 September 2017 at 11:57, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>>> On Tue, Sep 12, 2017 at 11:15 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)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