Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2023-02-21T20:16:11Z
Lists: pgsql-bugs
Andres Freund <andres@anarazel.de> writes: > Afaict this is a problem of a wrongly generated target list, which isn't what > ExecInterpExprStillValid() guards against: The targetlists are okay, really. The core problem is that each targetlist has an instance of the MULTIEXPR_SUBLINK SubPlan with a differently-mutated "args" list, and it looks to me like we correctly mutated that for the associated child table. But because all the instances share the same output Params, the ExecSetParamPlan mechanism gets confused about which version of the SubPlan it ought to invoke to recompute the output Params. It occurs to me that one possible fix is to make MULTIEXPR_SUBLINK and the associated output Params use a separate ParamExecData array; instead of the query-wide es_param_exec_vals array, use one that is local to the specific targetlist's ExprState. I'm not sure how much violence that does to the current notion of an ExprState --- do we think that is read-only during execution? If we did have a local-to-the-expression ParamExecData array, maybe that could be used to get a cleaner fix for things like the domain VALUES and case-test-expression hacks. regards, tom lane
Commits
-
Fix MULTIEXPR_SUBLINK with partitioned target tables, yet again.
- ffec64ba86c4 11.20 landed
- a033f9165c2c 15.3 landed
- 9eaba06027ae 14.8 landed
- 904b171a4655 12.15 landed
- 87f3667ec079 16.0 landed
- 1e199c259947 13.11 landed
-
Repair rare failure of MULTIEXPR_SUBLINK subplans in inherited updates.
- 3f7323cbbdd3 13.9 cited