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

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: ashutosh(dot)bapat(at)enterprisedb(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)2ndquadrant(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Problem while updating a foreign table pointing to a partitioned table on foreign server
Date: 2018-08-08 08:30:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello. Please find the attached.

At Fri, 3 Aug 2018 11:48:38 +0530, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote in <CAFjFpRcF-j+B8W8o-wrvOguA0=r8SJ-rCrzWAnHT2V66NxGfFQ(at)mail(dot)gmail(dot)com>
> The purpose of non-Var node is to avoid adding the attribute to
> relation descriptor. Idea is to create a new node, which will act as a
> place holder for table oid or row id (whatever) to be fetched from the
> foreign server. I don't understand why do you think we need it to be
> added to the relation descriptor.

I choosed to expand tuple descriptor for junk column added to
foreign relaions. We might be better to have new member in
ForeignScan but I didn't so that we can backpatch it.

What the patch does are:

- This abuses ForeignScan->fdw_scan_tlist to store the additional
junk columns when foreign simple relation scan (that is, not a

Several places seems to be assuming that fdw_scan_tlist may be
used foreign scan on simple relation but I didn't find that
actually happens. This let us avoid adding new data members to
core data structure. Separate member would be preferable for
new version.

- The remote OID request is added to targetlist as a non-system
junk column. get_relation_info exands per-column storage in
creating RelOptInfo so that the additional junk columns can be

- ExecInitForeignScan is changed so that it expands created tuple
descriptor if it finds the junk columns stored in
fdw_scan_tlist so that make_tuple_from_result_row can store
them. ( ExecEvalWholeRowVar needed to modify so that it ignores
the expanded portion of tuple descriptor.)

I'm not sure whether the following ponits are valid.

- If fdw_scan_tlist is used for simple relation scans, this would
break the case. (ExecInitForeignScan, set_foreignscan_references)

- I'm using the name "tableoid" for the junk column but it also
can be used in user query. The two points to different targets
so it doesn't matter at all, except that it makes a bit
confusing explain output.

- Explain stuff doesn't have a crue for the name of the added
junk. It is shown as <added_junk> in EXPLAIN output.

| Update on public.fp
| Remote SQL: UPDATE public.p SET b = $3 WHERE tableoid = $1 AND ctid = $2
| -> Foreign Scan on public.fp
| Output: a, (b + 1), "<added_junk>", ctid
| Filter: (random() <= '1'::double precision)
| Remote SQL: SELECT a, b, tableoid AS __remote_tableoid, ctid
| FROM public.p WHERE ((a = 0)) FOR UPDATE


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v1-0002-Regression-test-for-update-delete-on-foreign-partiti.patch text/x-patch 26.9 KB
v1-0001-Fix-foreign-update-on-remote-partitioned-tables.patch text/x-patch 29.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-08-08 08:33:06 Re: Temporary tables prevent autovacuum, leading to XID wraparound
Previous Message Marina Polyakova 2018-08-08 08:02:01 Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors