database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-16 17:07:43 +03:00
Code Activity

Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch.

Browse Source 
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
This commit is contained in:
Etsuro Fujita
2025-10-15 17:15:05 +09:00
parent 75a555d61b
commit 12b0c0e51b
5 changed files with 111 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
contrib/postgres_fdw/.gitignore vendored
View File

@@ -1,4 +1,6 @@
# Generated subdirectories
/log/
/results/
/output_iso/
/tmp_check/
/tmp_check_iso/

2
contrib/postgres_fdw/Makefile
View File

@@ -17,6 +17,8 @@ EXTENSION = postgres_fdw
DATA = postgres_fdw--1.0.sql
REGRESS = postgres_fdw
ISOLATION = eval_plan_qual
ISOLATION_OPTS = --load-extension=postgres_fdw
ifdef USE_PGXS
PG_CONFIG = pg_config

37
contrib/postgres_fdw/expected/eval_plan_qual.out Normal file
View File

@@ -0,0 +1,37 @@
Parsed test spec with 2 sessions
starting permutation: s0_begin s0_update s1_begin s1_tuplock s0_commit s1_commit
step s0_begin: BEGIN ISOLATION LEVEL READ COMMITTED;
step s0_update: UPDATE a SET i = i + 1;
step s1_begin: BEGIN ISOLATION LEVEL READ COMMITTED;
step s1_tuplock:
-- Verify if the sub-select has a foreign-join plan
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: <... completed>
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
LockRows
Output: a.i, ((SubPlan 1)), a.ctid
-> Seq Scan on public.a
Output: a.i, (SubPlan 1), a.ctid
SubPlan 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;

55
contrib/postgres_fdw/specs/eval_plan_qual.spec Normal file
View File

@@ -0,0 +1,55 @@
# Tests for the EvalPlanQual mechanism involving foreign tables
setup
{
DO $d$
BEGIN
EXECUTE $$CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname '$$||current_database()||$$',
port '$$||current_setting('port')||$$'
)$$;
END;
$d$;
CREATE USER MAPPING FOR PUBLIC SERVER loopback;
CREATE TABLE a (i int);
CREATE TABLE b (i int);
CREATE TABLE c (i int);
CREATE FOREIGN TABLE fb (i int) SERVER loopback OPTIONS (table_name 'b');
CREATE FOREIGN TABLE fc (i int) SERVER loopback OPTIONS (table_name 'c');
INSERT INTO a VALUES (1);
INSERT INTO b VALUES (1);
INSERT INTO c VALUES (1);
}
teardown
{
DROP TABLE a;
DROP TABLE b;
DROP TABLE c;
DROP SERVER loopback CASCADE;
}
session s0
step s0_begin { BEGIN ISOLATION LEVEL READ COMMITTED; }
step s0_update { UPDATE a SET i = i + 1; }
step s0_commit { COMMIT; }
session s1
step s1_begin { BEGIN ISOLATION LEVEL READ COMMITTED; }
step s1_tuplock {
-- Verify if the sub-select has a foreign-join plan
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;
}
step s1_commit { COMMIT; }
# This test exercises EvalPlanQual with a SubLink sub-select (which should
# be unaffected by any EPQ recheck behavior in the outer query).
permutation s0_begin s0_update s1_begin s1_tuplock s0_commit s1_commit

22
src/backend/executor/execScan.c
View File

@@ -55,16 +55,24 @@ ExecScanFetch(ScanState *node,
{
/*
* This is a ForeignScan or CustomScan which has pushed down a
* join to the remote side. The recheck method is responsible not
* only for rechecking the scan/join quals but also for storing
* the correct tuple in the slot.
* join to the remote side. If it is a descendant node in the EPQ
* recheck plan tree, run the recheck method function. Otherwise,
* run the access method function below.
*/
if (bms_is_member(epqstate->epqParam, node->ps.plan->extParam))
{
/*
* The recheck method is responsible not only for rechecking
* the scan/join quals but also for storing the correct tuple
* in the slot.
*/
TupleTableSlot *slot = node->ss_ScanTupleSlot;
TupleTableSlot *slot = node->ss_ScanTupleSlot;
if (!(*recheckMtd) (node, slot))
ExecClearTuple(slot); /* would not be returned by scan */
return slot;
if (!(*recheckMtd) (node, slot))
ExecClearTuple(slot); /* would not be returned by scan */
return slot;
}
}
else if (epqstate->relsubs_done[scanrelid - 1])
{