public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES 3+ messages / 1 participants [nested] [flat]
* pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES @ 2025-03-13 16:13 Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2025-03-13 16:13 UTC (permalink / raw) To: [email protected] Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES. Letting the rewriter keep RangeTblEntry.relid when expanding a view RTE, without making the outfuncs/readfuncs changes that went along with that originally, is more problematic than I realized. It causes WRITE_READ_PARSE_PLAN_TREES testing to fail because outfuncs/readfuncs don't think relid need be saved in an RTE_SUBQUERY RTE. There doesn't seem to be any other good route to fixing the whole-row Var problem solved at f4e7756ef, so we just have to deal with the consequences. We can make the eventually-produced plan tree safe for WRITE_READ_PARSE_PLAN_TREES by clearing the relid field at the end of planning, as was already being done for the functions field. (The functions field is not problematic here because our abuse of it is strictly local to the planner.) However, there is no nice fix for the post-rewrite WRITE_READ_PARSE_PLAN_TREES test. The solution adopted here is to remove the post-rewrite test in the affected branches. That's surely less than ideal, but a couple of arguments can be made why it's not unacceptable. First, the behavior of outfuncs/readfuncs for parsetrees in these branches is frozen no matter what, because of catalog stability requirements. So we're not testing anything that is going to change. Second, testing WRITE_READ_PARSE_PLAN_TREES at this particular time doesn't correspond to any direct system functionality requirement, neither rule storage nor plan transmission. Reported-by: Andres Freund <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13-15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7713f4592ad0c1c6de10ad881e27dad5d1dd3428 Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 9 ++++++++ src/backend/rewrite/rewriteHandler.c | 4 ++-- src/backend/tcop/postgres.c | 43 ++++-------------------------------- src/include/nodes/parsenodes.h | 4 ++-- 4 files changed, 17 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES @ 2025-03-13 16:13 Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2025-03-13 16:13 UTC (permalink / raw) To: [email protected] Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES. Letting the rewriter keep RangeTblEntry.relid when expanding a view RTE, without making the outfuncs/readfuncs changes that went along with that originally, is more problematic than I realized. It causes WRITE_READ_PARSE_PLAN_TREES testing to fail because outfuncs/readfuncs don't think relid need be saved in an RTE_SUBQUERY RTE. There doesn't seem to be any other good route to fixing the whole-row Var problem solved at f4e7756ef, so we just have to deal with the consequences. We can make the eventually-produced plan tree safe for WRITE_READ_PARSE_PLAN_TREES by clearing the relid field at the end of planning, as was already being done for the functions field. (The functions field is not problematic here because our abuse of it is strictly local to the planner.) However, there is no nice fix for the post-rewrite WRITE_READ_PARSE_PLAN_TREES test. The solution adopted here is to remove the post-rewrite test in the affected branches. That's surely less than ideal, but a couple of arguments can be made why it's not unacceptable. First, the behavior of outfuncs/readfuncs for parsetrees in these branches is frozen no matter what, because of catalog stability requirements. So we're not testing anything that is going to change. Second, testing WRITE_READ_PARSE_PLAN_TREES at this particular time doesn't correspond to any direct system functionality requirement, neither rule storage nor plan transmission. Reported-by: Andres Freund <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13-15 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1a20bc94623e6ee5041713fc66b7f803832f0bba Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 9 ++++++++ src/backend/rewrite/rewriteHandler.c | 4 ++-- src/backend/tcop/postgres.c | 43 ++++-------------------------------- src/include/nodes/parsenodes.h | 4 ++-- 4 files changed, 17 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES @ 2025-03-13 16:13 Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2025-03-13 16:13 UTC (permalink / raw) To: [email protected] Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES. Letting the rewriter keep RangeTblEntry.relid when expanding a view RTE, without making the outfuncs/readfuncs changes that went along with that originally, is more problematic than I realized. It causes WRITE_READ_PARSE_PLAN_TREES testing to fail because outfuncs/readfuncs don't think relid need be saved in an RTE_SUBQUERY RTE. There doesn't seem to be any other good route to fixing the whole-row Var problem solved at f4e7756ef, so we just have to deal with the consequences. We can make the eventually-produced plan tree safe for WRITE_READ_PARSE_PLAN_TREES by clearing the relid field at the end of planning, as was already being done for the functions field. (The functions field is not problematic here because our abuse of it is strictly local to the planner.) However, there is no nice fix for the post-rewrite WRITE_READ_PARSE_PLAN_TREES test. The solution adopted here is to remove the post-rewrite test in the affected branches. That's surely less than ideal, but a couple of arguments can be made why it's not unacceptable. First, the behavior of outfuncs/readfuncs for parsetrees in these branches is frozen no matter what, because of catalog stability requirements. So we're not testing anything that is going to change. Second, testing WRITE_READ_PARSE_PLAN_TREES at this particular time doesn't correspond to any direct system functionality requirement, neither rule storage nor plan transmission. Reported-by: Andres Freund <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13-15 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b200180dec98d1e5e5fd91b09fc543e8c09db9d0 Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 9 ++++++++ src/backend/rewrite/rewriteHandler.c | 4 ++-- src/backend/tcop/postgres.c | 43 ++++-------------------------------- src/include/nodes/parsenodes.h | 4 ++-- 4 files changed, 17 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-03-13 16:13 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-13 16:13 pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES Tom Lane <[email protected]> 2025-03-13 16:13 pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES Tom Lane <[email protected]> 2025-03-13 16:13 pgsql: Repair commits 317aba70e et al for -DWRITE_READ_PARSE_PLAN_TREES Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox