On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > As Tom mentioned, just recomputing the original join tuple is not good > enough. We would need to rejoin the test tuples for the baserels even if > ROW_MARK_COPY is in use. Consider: > > A=# BEGIN; > A=# UPDATE t SET a = a + 1 WHERE b = 1; > B=# SELECT * from t, ft1, ft2 > WHERE t.a = ft1.a AND t.b = ft2.b AND ft1.c = ft2.c FOR UPDATE; > A=# COMMIT; > > where the plan for the SELECT FOR UPDATE is > > LockRows > -> Nested Loop > -> Seq Scan on t > -> Foreign Scan on <ft1, ft2> > Remote SQL: SELECT * FROM ft1 JOIN ft2 WHERE ft1.c = ft2.c AND ft1.a > = $1 AND ft2.b = $2 > > If an EPQ recheck is invoked by the A's UPDATE, just recomputing the > original join tuple from the whole-row image that you proposed would output > an incorrect result in the EQP recheck since the value a in the updated > version of a to-be-joined tuple in t would no longer match the value ft1.a > extracted from the whole-row image if the A's UPDATE has committed > successfully. So I think we would need to rejoin the tuples populated from > the whole-row images for the baserels ft1 and ft2, by executing the > secondary plan with the new parameter values for a and b.
No. You just need to populate fdw_recheck_quals correctly, same as for the scan case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers