Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables
Date
Msg-id CAFiTN-v_WOycpycrh2c_TpzVU=yOjMNWwHnUYYxccK-fOaWjpw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Bug in ExecModifyTable function and trigger issues for foreigntables  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
Responses Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables
List pgsql-hackers
On Sun, May 14, 2017 at 5:35 PM, Ildus Kurbangaliev
<i.kurbangaliev@postgrespro.ru> wrote:
> TRAP: FailedAssertion("!(((const void*)(fdw_trigtuple) != ((void *)0))
> ^ ((bool) (((const void*)(tupleid) != ((void *)0)) &&
> ((tupleid)->ip_posid != 0))))", File: "trigger.c", Line: 2428)
>
> I'm not sure how it should be fixed, because as I see `oldtuple` will
> be set only for AFTER ROW triggers by `wholerow` junk attribute.

There is comment on the ExecUpdate function
*  When updating a foreign table,* tupleid is invalid; the FDW has to figure out which row to* update using data from
theplanSlot.  oldtuple is passed to* foreign table triggers; it is NULL when the foreign table has* no relevant
triggers.

After your fix, now tupleid is invalid which is expected, but seems
like we need to do something more. As per the comments seems like it
is expected to get the oldtuple from planSlot.  But I don't see any
code for handling that part.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: [HACKERS] PG10 pgindent run
Next
From: Sokolov Yura
Date:
Subject: [HACKERS] Small improvement to compactify_tuples