pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix setrefs.c's failure to do expression processing on prune ste 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix setrefs.c's failure to do expression processing on prune ste @ 2025-01-17 01:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-01-17 01:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix setrefs.c's failure to do expression processing on prune steps. We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/bf826ea062979da02395fb2e8961feeef47604da Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 12 +++++++++++ src/test/regress/expected/partition_prune.out | 29 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 15 ++++++++++++++ 3 files changed, 56 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix setrefs.c's failure to do expression processing on prune ste @ 2025-01-17 01:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-01-17 01:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix setrefs.c's failure to do expression processing on prune steps. We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0671a71e0210f7a3be55af240e9e7bbbea3cb44d Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 12 +++++++++++ src/test/regress/expected/partition_prune.out | 29 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 15 ++++++++++++++ 3 files changed, 56 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix setrefs.c's failure to do expression processing on prune ste @ 2025-01-17 01:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-01-17 01:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix setrefs.c's failure to do expression processing on prune steps. We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/94c02bd3345d7837bc1f240c14db2222c85aa18c Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 12 +++++++++++ src/test/regress/expected/partition_prune.out | 29 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 15 ++++++++++++++ 3 files changed, 56 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix setrefs.c's failure to do expression processing on prune ste @ 2025-01-17 01:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-01-17 01:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix setrefs.c's failure to do expression processing on prune steps. We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/724ebebb110493f2000114404188cc3e935153f6 Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 12 +++++++++++ src/test/regress/expected/partition_prune.out | 29 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 15 ++++++++++++++ 3 files changed, 56 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix setrefs.c's failure to do expression processing on prune ste @ 2025-01-17 01:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-01-17 01:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix setrefs.c's failure to do expression processing on prune steps. We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5f725648fa3b29ffcf25c8c5123cdd9a36642862 Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 12 +++++++++++ src/test/regress/expected/partition_prune.out | 29 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 15 ++++++++++++++ 3 files changed, 56 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix setrefs.c's failure to do expression processing on prune ste @ 2025-01-17 01:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-01-17 01:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix setrefs.c's failure to do expression processing on prune steps. We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/45004f527afaf415f88272710883e9c473b5a2f6 Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 12 ++++++++++ src/test/regress/expected/partition_prune.out | 32 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 15 +++++++++++++ 3 files changed, 59 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-01-17 01:40 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-01-17 01:40 pgsql: Fix setrefs.c's failure to do expression processing on prune ste Tom Lane <tgl@sss.pgh.pa.us> 2025-01-17 01:40 pgsql: Fix setrefs.c's failure to do expression processing on prune ste Tom Lane <tgl@sss.pgh.pa.us> 2025-01-17 01:40 pgsql: Fix setrefs.c's failure to do expression processing on prune ste Tom Lane <tgl@sss.pgh.pa.us> 2025-01-17 01:40 pgsql: Fix setrefs.c's failure to do expression processing on prune ste Tom Lane <tgl@sss.pgh.pa.us> 2025-01-17 01:40 pgsql: Fix setrefs.c's failure to do expression processing on prune ste Tom Lane <tgl@sss.pgh.pa.us> 2025-01-17 01:40 pgsql: Fix setrefs.c's failure to do expression processing on prune ste Tom Lane <tgl@sss.pgh.pa.us>
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