Re: Foreign join pushdown vs EvalPlanQual

On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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