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

Hello.

At Fri, 1 Jun 2018 10:21:39 -0400, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote in <CAFjFpRdraYcQnD4tKzNuP1uP6L-gnizi4HLU_UA=28Q2M4zoDA(at)mail(dot)gmail(dot)com>
> I am not suggesting to commit 0003 in my patch set, but just 0001 and
> 0002 which just raise an error when multiple rows get updated when
> only one row is expected to be updated.

I reconsidered Tom's suggestion and found a way to fix this
problem avoiding FDW-API change.

To make use of PARAM_EXECs here, the attached PoC patch does the
following things. No changes in the core side.

- postgresAddForeignUpdateTargets is no longer useful, thus it is
removed from fdw_function in the attached patch.

- GetForeignRelSize registers table oid and ctid columns into
attrs_used and a new member param_attrs on updates.

- postgresGetForeignPlan assigns two PARAM_EXECs for the two
values, then remember the paramids in fdw_private.

- postgresPlanForeignModify searches for the parameters and
remember their paramids.

After that, doing the following things fixes the issue.

- make_tuple_tuple_from_result_row receives remote table oid and
stores it to the returned tuples.

- postgresIterateForeignScan stores the values into remembered
parameters.

- postgresExecForeignUpdate/Delete read the parameters and
specify remote victims using them accurately.

It fails on some join-pushdown cases since it doesn't add tid
columns to join tlist. I suppose that build_tlist_to_deparse
needs something but I'll consider further tomorrow.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center