Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
От | Tom Lane |
---|---|
Тема | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash |
Дата | |
Msg-id | 3990862.1677010571@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
|
Список | 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
В списке pgsql-bugs по дате отправления: