pgsql: Fix EPQ crash from missing partition directory in EState
Fix EPQ crash from missing partition directory in EState EvalPlanQualStart() failed to propagate es_partition_directory into the child EState used for EPQ rechecks. When execution time partition pruning ran during the EPQ scan, executor code dereferenced a NULL partition directory and crashed. Previously, propagating es_partition_directory into the EPQ EState was unnecessary because CreatePartitionPruneState(), which sets it on demand, also initialized the exec-pruning context. After commit d47cbf474, CreatePartitionPruneState() now initializes only the init- time pruning context, leaving exec-pruning context initialization to ExecInitNode(). Since EvalPlanQualStart() runs only ExecInitNode() and not CreatePartitionPruneState(), it can encounter a NULL es_partition_directory. Other executor fields initialized during CreatePartitionPruneState() are already copied into the child EState thanks to commit 8741e48e5d, but es_partition_directory was missed. Fix by borrowing the parent estate's es_partition_directory in EvalPlanQualStart(), and by clearing that field in EvalPlanQualEnd() so the parent remains responsible for freeing the directory. Add an isolation test permutation that triggers EPQ with execution- time partition pruning, the case that reproduces this crash. Bug: #19078 Reported-by: Yuri Zamyatin Diagnosed-by: David Rowley Author: David Rowley Co-authored-by: Amit Langote Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1296dcf18b1cf3a064e5981c1655d133f0b1206f Modified Files -- src/backend/executor/execMain.c| 10 ++ src/test/isolation/expected/eval-plan-qual.out | 7 +++ src/test/isolation/specs/eval-plan-qual.spec | 2 ++ 3 files changed, 19 insertions(+)
pgsql: Refactor logical worker synchronization code into a separate fil
Refactor logical worker synchronization code into a separate file. To support the upcoming addition of a sequence synchronization worker, this patch extracts common synchronization logic shared by table sync workers and the new sequence sync worker into a dedicated file. This modularization improves code reuse, maintainability, and clarity in the logical workers framework. Author: vignesh C Author: Hou Zhijie Reviewed-by: shveta malik Reviewed-by: Dilip Kumar Reviewed-by: Peter Smith Reviewed-by: Hayato Kuroda Reviewed-by: Chao Li Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/caa4ek1lc+kjiaksrpe_nwvndidw9f2os7geruesxskv71gx...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/41c674d2e31e8304a6edbcb5183d326798ba00f6 Modified Files -- src/backend/catalog/pg_subscription.c | 4 +- src/backend/replication/logical/Makefile | 1 + .../replication/logical/applyparallelworker.c | 2 +- src/backend/replication/logical/meson.build| 1 + src/backend/replication/logical/syncutils.c| 187 src/backend/replication/logical/tablesync.c| 196 +++-- src/backend/replication/logical/worker.c | 22 +-- src/bin/pg_dump/common.c | 4 +- src/bin/pg_dump/pg_dump.c | 8 +- src/bin/pg_dump/pg_dump.h | 2 +- src/include/catalog/pg_subscription_rel.h | 2 +- src/include/replication/worker_internal.h | 14 +- src/tools/pgindent/typedefs.list | 2 +- 13 files changed, 243 insertions(+), 202 deletions(-)
pgsql: Fix EvalPlanQual handling of foreign/custom joins in ExecScanFet
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 Author: Masahiko Sawada Co-authored-by: Etsuro Fujita Reviewed-by: Michael Paquier Reviewed-by: Etsuro Fujita Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nuw3xpq64v35fpdeksternc...@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(-)
pgsql: Add tests for logging of temporary file removal and statement
Add tests for logging of temporary file removal and statement Temporary file usage is sometimes attributed to the wrong query in the logs output. One identified reason is that unnamed portal cleanup (and consequently temp file logging) happens during the next BIND message as a, after debug_query_string has already been updated to the new query. Dropping an unnamed portal in the next BIND message is a rather old protocol behavior (fe19e56c572f, also mentioned in the docs). log_temp_files is a bit newer than that, as of be8a4318815. This commit adds tests to track which query is displayed next to the temporary file(s) removed when a portal is dropped, and in some cases if a query is displayed or not. We have not concluded how to improve the situation yet; these tests will at least help in checking what changes in the logs depending on the proposal discussed and how it affects the scenarios tracked by this new test. Author: Sami Imseih Author: Frédéric Yhuel Reviewed-by: Mircea Cadariu Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/76bba033128acd8bde70f532383f80b26cc9baae Modified Files -- src/test/modules/test_misc/meson.build | 1 + src/test/modules/test_misc/t/009_log_temp_files.pl | 141 + 2 files changed, 142 insertions(+)
