Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
Date
Msg-id 5AF59131.60001@lab.ntt.co.jp
Whole thread Raw
In response to Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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 by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
Next
From: Simon Riggs
Date:
Subject: Re: Indexes on partitioned tables and foreign partitions