Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-14T00:45:10Z
Lists: pgsql-hackers
On 2018/05/11 21:48, Etsuro Fujita wrote:
> (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 :(.

Ah, I see.  Thanks for clarifying.

> But considering there seems to be no field reports on that, I don't
> think we need back-patching up to 9.5.

Yeah, that might be fine, although it perhaps wouldn't hurt to have the
code match in all branches.

Thanks,
Amit



Commits

  1. Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify.

  2. postgres_fdw: Push down UPDATE/DELETE joins to remote servers.