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

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: ashutosh(dot)bapat(at)enterprisedb(dot)com, 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-09 13:04:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

(2018/08/08 17:30), Kyotaro HORIGUCHI wrote:
> Please find the attached.

Thanks for the patch, Horiguchi-san!

> 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 think so too.

>> I don't understand why do you think we need it to be
>> added to the relation descriptor.

I don't understand that either.

> 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.

I've not looked at the patch closely yet, but I'm not sure that it's a
good idea to expand the tuple descriptor of the target relation on the
fly so that it contains the remotetableoid as a non-system attribute of
the target table. My concern is: is there not any risk in affecting
some other part of the planner and/or the executor? (I was a bit
surprised that the patch passes the regression tests successfully.)

To avoid expanding the tuple descriptor, I'm wondering whether we could
add a Param representing remotetableoid, not a Var undefined anywhere in
the system catalogs, as mentioned above?

> 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
> join).

I think that this issue was introduced in 9.3, which added postgres_fdw
in combination with support for writable foreign tables, but
fdw_scan_tlist was added to 9.5 as part of join-pushdown infrastructure,
so my concern is that we might not be able to backpatch your patch to
9.3 and 9.4.

That's it for now.

Best regards,
Etsuro Fujita

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-08-09 13:31:44 Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Previous Message Andrew Dunstan 2018-08-09 13:00:34 Re: commitfest 2018-07