You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
postgres/contrib/postgres_fdw/expected/eval_plan_qual.out

132 lines
9.7 KiB

Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch. If inside an EPQ recheck, ExecScanFetch would run the recheck method function for foreign/custom joins even if they aren't descendant nodes in the EPQ recheck plan tree, which is problematic at least in the foreign-join case, because such a foreign join isn't guaranteed to have an alternative local-join plan required for running the recheck method function; in the postgres_fdw case this could lead to a segmentation fault or an assert failure in an assert-enabled build when running the recheck method function. Even if inside an EPQ recheck, any scan nodes that aren't descendant ones in the EPQ recheck plan tree should be normally processed by using the access method function; fix by modifying ExecScanFetch so that if inside an EPQ recheck, it runs the recheck method function for foreign/custom joins that are descendant nodes in the EPQ recheck plan tree as before and runs the access method function for foreign/custom joins that aren't. This fix also adds to postgres_fdw an isolation test for an EPQ recheck that caused issues stated above. Oversight in commit 385f337c9. Reported-by: Kristian Lejao <kristianlejao@gmail.com> Author: Masahiko Sawada <sawada.mshk@gmail.com> Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nUw3Xpq64v35fpDEKsTERnc4TQ@mail.gmail.com Backpatch-through: 13
2 months ago
Parsed test spec with 2 sessions
starting permutation: s0_update_l s1_tuplock_l_0 s0_commit s1_commit
step s0_update_l: UPDATE l SET i = i + 1;
step s1_tuplock_l_0:
EXPLAIN (VERBOSE, COSTS OFF)
SELECT l.* FROM l, ft WHERE l.i = ft.i AND l.i = 123 FOR UPDATE OF l;
SELECT l.* FROM l, ft WHERE l.i = ft.i AND l.i = 123 FOR UPDATE OF l;
<waiting ...>
step s0_commit: COMMIT;
step s1_tuplock_l_0: <... completed>
QUERY PLAN
---------------------------------------------------------------------
LockRows
Output: l.i, l.v, l.ctid, ft.*
-> Nested Loop
Output: l.i, l.v, l.ctid, ft.*
-> Seq Scan on public.l
Output: l.i, l.v, l.ctid
Filter: (l.i = 123)
-> Foreign Scan on public.ft
Output: ft.*, ft.i
Remote SQL: SELECT i, v FROM public.t WHERE ((i = 123))
(10 rows)
i|v
-+-
(0 rows)
step s1_commit: COMMIT;
starting permutation: s0_update_l s1_tuplock_l_1 s0_commit s1_commit
step s0_update_l: UPDATE l SET i = i + 1;
step s1_tuplock_l_1:
EXPLAIN (VERBOSE, COSTS OFF)
SELECT l.* FROM l, ft WHERE l.i = ft.i AND l.v = 'foo' FOR UPDATE OF l;
SELECT l.* FROM l, ft WHERE l.i = ft.i AND l.v = 'foo' FOR UPDATE OF l;
<waiting ...>
step s0_commit: COMMIT;
step s1_tuplock_l_1: <... completed>
QUERY PLAN
-----------------------------------------------------------------------------
LockRows
Output: l.i, l.v, l.ctid, ft.*
-> Nested Loop
Output: l.i, l.v, l.ctid, ft.*
-> Seq Scan on public.l
Output: l.i, l.v, l.ctid
Filter: (l.v = 'foo'::text)
-> Foreign Scan on public.ft
Output: ft.*, ft.i
Remote SQL: SELECT i, v FROM public.t WHERE ((i = $1::integer))
(10 rows)
i|v
-+-
(0 rows)
step s1_commit: COMMIT;
starting permutation: s0_update_a s1_tuplock_a_0 s0_commit s1_commit
step s0_update_a: UPDATE a SET i = i + 1;
step s1_tuplock_a_0:
EXPLAIN (VERBOSE, COSTS OFF)
SELECT a.i FROM a, fb, fc WHERE a.i = fb.i AND fb.i = fc.i FOR UPDATE OF a;
SELECT a.i FROM a, fb, fc WHERE a.i = fb.i AND fb.i = fc.i FOR UPDATE OF a;
<waiting ...>
step s0_commit: COMMIT;
step s1_tuplock_a_0: <... completed>
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
LockRows
Output: a.i, a.ctid, fb.*, fc.*
-> Nested Loop
Output: a.i, a.ctid, fb.*, fc.*
Join Filter: (fb.i = a.i)
-> Foreign Scan
Output: fb.*, fb.i, fc.*, fc.i
Relations: (public.fb) INNER JOIN (public.fc)
Remote SQL: SELECT CASE WHEN (r2.*)::text IS NOT NULL THEN ROW(r2.i) END, r2.i, CASE WHEN (r3.*)::text IS NOT NULL THEN ROW(r3.i) END, r3.i FROM (public.b r2 INNER JOIN public.c r3 ON (((r2.i = r3.i))))
-> Nested Loop
Output: fb.*, fb.i, fc.*, fc.i
Join Filter: (fb.i = fc.i)
-> Foreign Scan on public.fb
Output: fb.*, fb.i
Remote SQL: SELECT i FROM public.b ORDER BY i ASC NULLS LAST
-> Foreign Scan on public.fc
Output: fc.*, fc.i
Remote SQL: SELECT i FROM public.c
-> Seq Scan on public.a
Output: a.i, a.ctid
(20 rows)
i
-
(0 rows)
step s1_commit: COMMIT;
starting permutation: s0_update_a s1_tuplock_a_1 s0_commit s1_commit
step s0_update_a: UPDATE a SET i = i + 1;
step s1_tuplock_a_1:
Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch. If inside an EPQ recheck, ExecScanFetch would run the recheck method function for foreign/custom joins even if they aren't descendant nodes in the EPQ recheck plan tree, which is problematic at least in the foreign-join case, because such a foreign join isn't guaranteed to have an alternative local-join plan required for running the recheck method function; in the postgres_fdw case this could lead to a segmentation fault or an assert failure in an assert-enabled build when running the recheck method function. Even if inside an EPQ recheck, any scan nodes that aren't descendant ones in the EPQ recheck plan tree should be normally processed by using the access method function; fix by modifying ExecScanFetch so that if inside an EPQ recheck, it runs the recheck method function for foreign/custom joins that are descendant nodes in the EPQ recheck plan tree as before and runs the access method function for foreign/custom joins that aren't. This fix also adds to postgres_fdw an isolation test for an EPQ recheck that caused issues stated above. Oversight in commit 385f337c9. Reported-by: Kristian Lejao <kristianlejao@gmail.com> Author: Masahiko Sawada <sawada.mshk@gmail.com> Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nUw3Xpq64v35fpDEKsTERnc4TQ@mail.gmail.com Backpatch-through: 13
2 months ago
EXPLAIN (VERBOSE, COSTS OFF)
SELECT a.i,
(SELECT 1 FROM fb, fc WHERE a.i = fb.i AND fb.i = fc.i)
FROM a FOR UPDATE;
SELECT a.i,
(SELECT 1 FROM fb, fc WHERE a.i = fb.i AND fb.i = fc.i)
FROM a FOR UPDATE;
<waiting ...>
step s0_commit: COMMIT;
step s1_tuplock_a_1: <... completed>
Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch. If inside an EPQ recheck, ExecScanFetch would run the recheck method function for foreign/custom joins even if they aren't descendant nodes in the EPQ recheck plan tree, which is problematic at least in the foreign-join case, because such a foreign join isn't guaranteed to have an alternative local-join plan required for running the recheck method function; in the postgres_fdw case this could lead to a segmentation fault or an assert failure in an assert-enabled build when running the recheck method function. Even if inside an EPQ recheck, any scan nodes that aren't descendant ones in the EPQ recheck plan tree should be normally processed by using the access method function; fix by modifying ExecScanFetch so that if inside an EPQ recheck, it runs the recheck method function for foreign/custom joins that are descendant nodes in the EPQ recheck plan tree as before and runs the access method function for foreign/custom joins that aren't. This fix also adds to postgres_fdw an isolation test for an EPQ recheck that caused issues stated above. Oversight in commit 385f337c9. Reported-by: Kristian Lejao <kristianlejao@gmail.com> Author: Masahiko Sawada <sawada.mshk@gmail.com> Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nUw3Xpq64v35fpDEKsTERnc4TQ@mail.gmail.com Backpatch-through: 13
2 months ago
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
LockRows
Output: a.i, ((SubPlan expr_1)), a.ctid
-> Seq Scan on public.a
Output: a.i, (SubPlan expr_1), a.ctid
SubPlan expr_1
-> Foreign Scan
Output: 1
Relations: (public.fb) INNER JOIN (public.fc)
Remote SQL: SELECT NULL FROM (public.b r1 INNER JOIN public.c r2 ON (((r2.i = $1::integer)) AND ((r1.i = $1::integer))))
(9 rows)
i|?column?
-+--------
2|
(1 row)
step s1_commit: COMMIT;