Re: Bug in ExecModifyTable function and trigger issues for foreign tables

On Fri, Jun 16, 2017 at 3:35 PM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2017/06/16 0:05, Ildus Kurbangaliev wrote:
>
>
> I wrote:
>>>>>
>>>>> One approach I came up with to fix this issue is to rewrite the
>>>>> targetList entries of an inherited UPDATE/DELETE properly using
>>>>> rewriteTargetListUD, when generating a plan for each child table
>>>>> in inheritance_planner. Attached is a WIP patch for that. Maybe
>>>>> I am missing something, though.
>>>>
>>>>
>>>> While updating the patch, I noticed the patch rewrites the UPDATE
>>>> targetList incorrectly in some cases; rewrite_inherited_tlist I
>>>> added to adjust_appendrel_attrs (1) removes all junk items from the
>>>> targetList and (2) adds junk items for the child table using
>>>> rewriteTargetListUD, but it's wrong to drop all junk items in cases
>>>> where there are junk items for some other reasons than
>>>> rewriteTargetListUD. Consider junk items containing MULTIEXPR
>>>> SubLink. One way I came up with to fix this is to change (1) to
>>>> only remove junk items with resname; since junk items added by
>>>> rewriteTargetListUD should have resname (note: we would need
>>>> resname to call ExecFindJunkAttributeInTlist at execution time!)
>>>> while other junk items wouldn't have resname (see
>>>> transformUpdateTargetList), we could correctly replace junk items
>>>> added by rewriteTargetListUD for the parent with ones for the
>>>> child, by that change. I might be missing something, though.
>>>> Comments welcome.
>>>
>>>
>>> I updated the patch that way. Please find attached an updated
>>> version.
>>>
>>> Other changes:
>>> * Moved the initialization for "tupleid" I added in ExecModifyTable
>>> as discussed before, which I think is essentially the same as
>>> proposed by Ildus in [1], since I think that would be more consistent
>>> with "oldtuple".
>>> * Added regression tests.
>>>
>>> Anyway I'll add this to the next commitfest.
>
>
>> Checked the latest patch. Looks good.
>> Shouldn't this patch be backported to 9.6 and 10beta? The bug
>> affects them too.
>
>
> Thank you for the review!
>
> The bug is in foreign table inheritance, which was supported in 9.5, so I
> think this patch should be backported to 9.5.
>
> Ashutosh mentioned his concern about what I proposed above before [2], but
> I'm not sure we should address that. And there have been no opinions from
> him (or anyone else) since then. So, I'd like to leave that for committer
> (ie, +1 for Ready for Committer).

That issue has not been addressed. The reason stated was that it would
make code complicated. But I have not had chance to look at how
complicated would be and assess myself whether that's worth the
trouble. There was another issue

Also, I don't see any discussion about my concern [3] about a parent
with child from multiple foreign servers with different FDWs. So, I am
not sure whether the patch really fixes the problem in its entirety.

[3] https://www.postgresql.org/message-id/CAFjFpRfQ1pkCjNQFVOP_BPJfc7OR3596nqVVFBgAiDEZqB4Azg@mail.gmail.com

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company