From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] postgres_fdw bug in 9.6
Date: Fri, 08 Dec 2017 18:40:32 +0900
Message-ID: <5A2A5E10.1040604@lab.ntt.co.jp> (raw)
In-Reply-To: <85224.1512051763@sss.pgh.pa.us>
References: <CAMkU=1y2G8VOVBHv3iXU2TMAj7-RyBFFW1uhkr5sm9LQ2=X35g@mail.gmail.com>
<22168.1504041271@sss.pgh.pa.us>
<20170905044336.18925.22634.pgcf@coridan.postgresql.org>
<07ed8f27-12cf-8403-d23b-f7d907de4a83@lab.ntt.co.jp>
<CAFjFpRd7fuanj3s-bXpeuLhaRJnFuEWCiwu_-Q4Ox7wGCAW_Mw@mail.gmail.com>
<7031.1507215420@sss.pgh.pa.us>
<25877.1511886076@sss.pgh.pa.us>
<CA+TgmoaUu=QTvfoCVfidXH=CU4_e1nWTMj=jTQpB3eoHYAVpzw@mail.gmail.com>
<CAFjFpRc4f9u60t7VgTiw1quoto5gmXJ0tHMwCfSM5dx253B8fw@mail.gmail.com>
<27145.1511994722@sss.pgh.pa.us>
<5A1FFFD7.6080904@lab.ntt.co.jp>
<85224.1512051763@sss.pgh.pa.us>
(2017/11/30 23:22), Tom Lane wrote:
> Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp> writes:
>> (2017/11/30 7:32), Tom Lane wrote:
>>> the output of the foreign join cannot change during EPQ, since the remote
>>> server already locked the rows before returning them. The only thing that
>>> can change is the output of the local scan on public.tab. Yes, we then
>>> need to re-verify that foo.a = tab.a ... but in this example, that's the
>>> responsibility of the NestLoop plan node, not the foreign join.
>
>> That's right, but is that true when the FDW uses late row locking?
>
> An FDW using late row locking would need to work harder, yes. But
> that's true at the scan level as well as the join level. We have
> already committed to using early locking in postgres_fdw, for the
> network-round-trip-cost reasons I mentioned before, and I can't see
> why we'd change that decision at the join level.
My concern is FDWs that support join pushdown in combination with late
row locking. I don't know whether such FDWs really exist, but if so, an
output of a foreign join computed from re-fetched tuples might change.
> Right now we've got the worst of both worlds, in that we're actually
> doing early row locking on the remote, but we're paying (some of) the
> code complexity costs required for late locking.
Because we have provided the late row locking API, I think we should pay
a certain degree of consideration for such FDWs.
Best regards,
Etsuro Fujita
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: fujita.etsuro@lab.ntt.co.jp, tgl@sss.pgh.pa.us, ashutosh.bapat@enterprisedb.com, robertmhaas@gmail.com, jeff.janes@gmail.com, david@pgmasters.net
Subject: Re: [HACKERS] postgres_fdw bug in 9.6
In-Reply-To: <5A2A5E10.1040604@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox