pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/12609fbacb007698ec91101b6464436506518346 Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/meson.build | 6 +++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/include/executor/execScan.h | 22 +++++++--- 6 files changed, 117 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b141443259845de6901be70e8eaa090a483ab68f Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/meson.build | 6 +++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/include/executor/execScan.h | 22 +++++++--- 6 files changed, 117 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2bb84ea7ef89961ab3c02c4496a44b6335fc79e9 Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/meson.build | 6 +++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/backend/executor/execScan.c | 22 +++++++--- 6 files changed, 117 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5a9af48689dc4e67e1db305be9435866f158e9e0 Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/meson.build | 6 +++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/backend/executor/execScan.c | 22 +++++++--- 6 files changed, 117 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4a08603a232265b2ecd0595e80a15af3e92b04c8 Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/backend/executor/execScan.c | 22 +++++++--- 5 files changed, 111 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/24e74b9621e4e40a36ac03ee5e9f059787fefb5c Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/backend/executor/execScan.c | 22 +++++++--- 5 files changed, 111 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet @ 2025-10-15 08:18 Etsuro Fujita <efujita@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Etsuro Fujita @ 2025-10-15 08:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/12b0c0e51b2fed1f36816a0ea53a4f8e44455ec1 Modified Files -------------- contrib/postgres_fdw/.gitignore | 2 + contrib/postgres_fdw/Makefile | 2 + contrib/postgres_fdw/expected/eval_plan_qual.out | 37 ++++++++++++++++ contrib/postgres_fdw/specs/eval_plan_qual.spec | 55 ++++++++++++++++++++++++ src/backend/executor/execScan.c | 22 +++++++--- 5 files changed, 111 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2025-10-15 08:18 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org> 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org> 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org> 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org> 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org> 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org> 2025-10-15 08:18 pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet Etsuro Fujita <efujita@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox