Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
От | Etsuro Fujita |
---|---|
Тема | Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers |
Дата | |
Msg-id | 5AF59131.60001@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
|
Список | pgsql-hackers |
(2018/05/11 16:19), Amit Langote wrote: > On 2018/05/11 16:12, Amit Langote wrote: >> Just to clarify, does this problem only arise because there is a pushed >> down join involving the child? That is, does the problem only occur as of >> the following commit: >> >> commit 1bc0100d270e5bcc980a0629b8726a32a497e788 >> Author: Robert Haas<rhaas@postgresql.org> >> Date: Wed Feb 7 15:34:30 2018 -0500 >> >> postgres_fdw: Push down UPDATE/DELETE joins to remote servers. >> >> In other words, do we need to back-patch this up to 9.5 which added >> foreign table inheritance? > > Oops, it should have been clear by the subject line that the problem > didn't exist before that commit. Sorry. No. In theory, I think we could consider this as an older bug added in 9.5, because in case of inherited UPDATE/DELETE, the PlannerInfo passed to PlanForeignModify doesn't match the one the FDW saw at Path creation time, as you mentioned in a previous email, while in case of non-inherited UPDATE/DELETE, the PlannerInfo passed to that function matches the one the FDW saw at that time. I think that's my fault :(. But considering there seems to be no field reports on that, I don't think we need back-patching up to 9.5. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: