(2017/11/30 7:32), Tom Lane wrote:
> AFAICT, [1] just demonstrates that nobody had thought about the scenario
> up to that point, not that the subsequently chosen solution was a good
> one. In that example,
>
> LockRows (cost=100.00..101.18 rows=4 width=70)
> Output: tab.a, tab.b, tab.ctid, foo.*, bar.*
> -> Nested Loop (cost=100.00..101.14 rows=4 width=70)
> Output: tab.a, tab.b, tab.ctid, foo.*, bar.*
> Join Filter: (foo.a = tab.a)
> -> Seq Scan on public.tab (cost=0.00..1.01 rows=1 width=14)
> Output: tab.a, tab.b, tab.ctid
> -> Foreign Scan (cost=100.00..100.08 rows=4 width=64)
> Output: foo.*, foo.a, bar.*, bar.a
> Relations: (public.foo) INNER JOIN (public.bar)
> Remote SQL: SELECT l.a1, l.a2, r.a1, r.a2 FROM (SELECT ROW(l.a9), l.a9 FROM (SELECT a a9 FROM
public.fooFOR UPDATE) l) l (a1, a2) INNER JOIN (SELECT ROW(r.a9), r.a9 FROM (SELECT a a9 FROM public.bar FOR UPDATE) r)
r(a1, a2) ON ((l.a2 = r.a2))
>
> 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?
Best regards,
Etsuro Fujita
