(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.foo FOR 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
