Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server

(2018/08/30 21:58), Etsuro Fujita wrote:
> (2018/08/30 20:37), Kyotaro HORIGUCHI wrote:
>> At Fri, 24 Aug 2018 21:45:35 +0900, Etsuro
>> Fujita wrote
>> in<5B7FFDEF.6020302@lab.ntt.co.jp>
>>> (2018/08/21 11:01), Kyotaro HORIGUCHI wrote:
>>>> At Tue, 14 Aug 2018 20:49:02 +0900, Etsuro
>>>> Fujita wrote
>>>> in<5B72C1AE.8010408@lab.ntt.co.jp>
>>>>> (2018/08/09 22:04), Etsuro Fujita wrote:
>>>>>> (2018/08/08 17:30), Kyotaro HORIGUCHI wrote:
>>>
>>>>> I spent more time looking at the patch. ISTM that the patch well
>>>>> suppresses the effect of the tuple-descriptor expansion by making
>>>>> changes to code in the planner and executor (and ruleutils.c), but I'm
>>>>> still not sure that the patch is the right direction to go in, because
>>>>> ISTM that expanding the tuple descriptor on the fly might be a wart.
>>>
>>>> The exapansion should be safe if the expanded descriptor has the
>>>> same defitions for base columns and all the extended coulumns are
>>>> junks. The junk columns should be ignored by unrelated nodes and
>>>> they are passed safely as far as ForeignModify passes tuples as
>>>> is from underlying ForeignScan to ForeignUpdate/Delete.
>>>
>>> I'm not sure that would be really safe. Does that work well when
>>> EvalPlanQual, for example?

I was wrong here; I assumed here that we supported late locking for an 
UPDATE or DELETE on a foreign table, and I was a bit concerned that the 
approach you proposed might not work well with EvalPlanQual, but as 
described in fdwhandler.sgml, the core doesn't support for that:

      For an UPDATE or DELETE on a 
foreign table, it
      is recommended that the ForeignScan operation 
on the target
      table perform early locking on the rows that it fetches, perhaps 
via the
      equivalent of SELECT FOR UPDATE.  An FDW can 
detect whether
      a table is an UPDATE/DELETE 
target at plan time
      by comparing its relid to 
root->parse->resultRelation,
      or at execution time by using 
ExecRelationIsTargetRelation().
      An alternative possibility is to perform late locking within the
      ExecForeignUpdate or 
ExecForeignDelete
      callback, but no special support is provided for this.

So, there would be no need to consider about EvalPlanQual.  Sorry for 
the noise.

Best regards,
Etsuro Fujita