Re: [HACKERS] postgres_fdw bug in 9.6

(2017/11/30 23:22), Tom Lane wrote:
> Etsuro Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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