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  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: [HACKERS] Restrictions of logical replication
Следующее
От: Shubham Barai
Дата:
Сообщение: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index