Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables |
Дата | |
Msg-id | 0bc9c28b-96ca-c875-871e-16af6f53ecd9@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Bug in ExecModifyTable function and trigger issuesfor foreign tables (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>) |
Ответы |
Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables
|
Список | pgsql-hackers |
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). 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. Best regards, Etsuro Fujita [2] https://www.postgresql.org/message-id/CAFjFpRfTpamoUz6fNyk6gPh%3DecfBJjbUHJNKbDxscpyPJ3FfjQ%40mail.gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: