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

Hello.

At Wed, 05 Sep 2018 20:02:04 +0900, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <5B8FB7AC(dot)5020003(at)lab(dot)ntt(dot)co(dot)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(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote
> >> in<5B7FFDEF(dot)6020302(at)lab(dot)ntt(dot)co(dot)jp>
> >>> (2018/08/21 11:01), Kyotaro HORIGUCHI wrote:
> >>>> At Tue, 14 Aug 2018 20:49:02 +0900, Etsuro
> >>>> Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote
> >>>> in<5B72C1AE(dot)8010408(at)lab(dot)ntt(dot)co(dot)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-&gt;parse-&gt;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