Re: Bug in ExecModifyTable function and trigger issues for foreign tables
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
Dilip Kumar <dilipbalaut@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2017-06-16T10:05:47Z
Lists: pgsql-hackers
Attachments
- adjust-inherited-update-tlist-v2.patch (text/plain) patch v2
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
Commits
-
Fix creation of resjunk tlist entries for inherited mixed UPDATE/DELETE.
- 39f180fdd1e6 9.5.11 landed
- 06ba5309682e 9.6.7 landed
- a57aa430b613 10.2 landed
- 9a785ad57317 11.0 landed