|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>|
|Cc:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: Bug in ExecModifyTable function and trigger issues for foreign tables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2017/06/16 0:05, Ildus Kurbangaliev 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
>> 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 , 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 ,
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).
Attached is a slightly-updated version; I renamed some variables used in
rewrite_inherited_tlist() to match other existing code in prepunion.c
and revised some comments a bit. I didn't make any functional changes,
so I'll keep this Ready for Committer.
|Next Message||Shubham Barai||2017-06-16 10:24:13||GSoC 2017 : Patch for predicate locking in Gist index|
|Previous Message||Aleksander Alekseev||2017-06-16 10:00:28||Re: Restrictions of logical replication|