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-09-05 11:02:04 |
Message-ID: | 5B8FB7AC.5020003@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(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->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.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2018-09-05 11:39:08 | Re: Bug in ginRedoRecompress that causes opaque data on page to be overrun |
Previous Message | Christoph Berg | 2018-09-05 10:35:25 | Re: Collation versioning |