mirror of
https://github.com/postgres/postgres.git
synced 2026-04-14 21:47:31 -04:00
d9ebc582fb
Prior to v14, if we have a MULTIEXPR SubPlan (that is, use of the syntax UPDATE ... SET (c1, ...) = (SELECT ...)) in an UPDATE with an inherited or partitioned target table, inheritance_planner() will clone the targetlist and therefore also the MULTIEXPR SubPlan and the Param nodes referencing it for each child target table. Up to now, we've allowed all the clones to share the underlying subplan as well as the output parameter IDs -- that is, the runtime ParamExecData slots. That technique is borrowed from the far older code that supports initplans, and it works okay in that case because the cloned SubPlan nodes are essentially identical. So it doesn't matter which one of the clones the shared ParamExecData.execPlan field might point to. However, this fails to hold for MULTIEXPR SubPlans, because they can have nonempty "args" lists (values to be passed into the subplan), and those lists could get mutated to different states in the various clones. In the submitted reproducer, as well as the test case added here, one clone contains Vars with varno OUTER_VAR where another has INNER_VAR, because the child tables are respectively on the outer or inner side of the join. Sharing the execPlan pointer can result in trying to evaluate an args list that doesn't match the local execution state, with mayhem ensuing. The result often is to trigger consistency checks in the executor, but I believe this could end in a crash or incorrect updates. To fix, assign new Param IDs to each of the cloned SubPlans, so that they don't share ParamExecData slots at runtime. It still seems fine for the clones to share the underlying subplan, and extra ParamExecData slots are cheap enough that this fix shouldn't cost much. This has been busted since we invented MULTIEXPR SubPlans in 9.5. Probably the lack of previous reports is because query plans in which the different clones of a MULTIEXPR mutate to effectively-different states are pretty rare. There's no issue in v14 and later, because without inheritance_planner() there's never a reason to clone MULTIEXPR SubPlans. Per bug #17596 from Andre Lin. Patch v10-v13 only. Discussion: https://postgr.es/m/17596-c5357f61427a81dc@postgresql.org |
||
|---|---|---|
| .. | ||
| access | ||
| bootstrap | ||
| catalog | ||
| commands | ||
| common | ||
| datatype | ||
| executor | ||
| fe_utils | ||
| foreign | ||
| jit | ||
| lib | ||
| libpq | ||
| mb | ||
| nodes | ||
| optimizer | ||
| parser | ||
| partitioning | ||
| port | ||
| portability | ||
| postmaster | ||
| regex | ||
| replication | ||
| rewrite | ||
| snowball | ||
| statistics | ||
| storage | ||
| tcop | ||
| tsearch | ||
| utils | ||
| .gitignore | ||
| c.h | ||
| fmgr.h | ||
| funcapi.h | ||
| getaddrinfo.h | ||
| getopt_long.h | ||
| Makefile | ||
| miscadmin.h | ||
| pg_config.h.in | ||
| pg_config.h.win32 | ||
| pg_config_ext.h.in | ||
| pg_config_ext.h.win32 | ||
| pg_config_manual.h | ||
| pg_getopt.h | ||
| pg_trace.h | ||
| pgstat.h | ||
| pgtar.h | ||
| pgtime.h | ||
| port.h | ||
| postgres.h | ||
| postgres_ext.h | ||
| postgres_fe.h | ||
| rusagestub.h | ||
| windowapi.h | ||