Hello. At Wed, 05 Sep 2018 20:02:04 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote in <5b8fb7ac.5020...@lab.ntt.co.jp> > (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<fujita.ets...@lab.ntt.co.jp> wrote > >> in<5b7ffdef.6020...@lab.ntt.co.jp> > >>> (2018/08/21 11:01), Kyotaro HORIGUCHI wrote: > >>>> At Tue, 14 Aug 2018 20:49:02 +0900, Etsuro > >>>> Fujita<fujita.ets...@lab.ntt.co.jp> wrote > >>>> in<5b72c1ae.8010...@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 <command>UPDATE</command> or <command>DELETE</command> on a > foreign table, it > is recommended that the <literal>ForeignScan</literal> operation on > the target > table perform early locking on the rows that it fetches, perhaps via > the > equivalent of <command>SELECT FOR UPDATE</command>. An FDW can detect > whether > a table is an <command>UPDATE</command>/<command>DELETE</command> > target at plan time > by comparing its relid to > <literal>root->parse->resultRelation</literal>, > or at execution time by using > <function>ExecRelationIsTargetRelation()</function>. > An alternative possibility is to perform late locking within the > <function>ExecForeignUpdate</function> or > <function>ExecForeignDelete</function> > callback, but no special support is provided for this. > > So, there would be no need to consider about EvalPlanQual. Sorry for > the noise.
I don't think it is a noise at all. Thank you for the pointer. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
