Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUZ4j-0007gC-H6 for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Feb 2023 20:17:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUZ3j-0007OK-NS for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Feb 2023 20:16:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUZ3j-0007OB-F6 for pgsql-bugs@lists.postgresql.org; Tue, 21 Feb 2023 20:16:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUZ3g-0001g1-RC for pgsql-bugs@lists.postgresql.org; Tue, 21 Feb 2023 20:16:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 31LKGBtB3990863; Tue, 21 Feb 2023 15:16:11 -0500 From: Tom Lane To: Andres Freund cc: Michael Paquier , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash In-reply-to: <20230221193352.mvzpuvoujfmckvr3@awork3.anarazel.de> References: <17800-ff90866b3906c964@postgresql.org> <20230221193352.mvzpuvoujfmckvr3@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 21 Feb 2023 11:33:52 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3990861.1677010571.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2023 15:16:11 -0500 Message-ID: <3990862.1677010571@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund 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