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 1m1Wty-0007Tm-QK for pgsql-bugs@arkaria.postgresql.org; Thu, 08 Jul 2021 16:29:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m1Wtx-0004WM-CT for pgsql-bugs@arkaria.postgresql.org; Thu, 08 Jul 2021 16:29:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Wtx-0004WD-5u for pgsql-bugs@lists.postgresql.org; Thu, 08 Jul 2021 16:29:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Wtt-0007bz-Ib for pgsql-bugs@lists.postgresql.org; Thu, 08 Jul 2021 16:29:24 +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 168GTJv71974960; Thu, 8 Jul 2021 12:29:19 -0400 From: Tom Lane To: Richard Guo cc: cyg0810@gmail.com, PostgreSQL mailing lists Subject: Re: BUG #17094: FailedAssertion at planner.c In-reply-to: References: <17094-bf15dff55eaf2e28@postgresql.org> Comments: In-reply-to Richard Guo message dated "Thu, 08 Jul 2021 22:36:19 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1974958.1625761759.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 08 Jul 2021 12:29:19 -0400 Message-ID: <1974959.1625761759@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Thu, Jul 8, 2021 at 5:27 PM PG Bug reporting form > wrote: >> CREATE TABLE v0 ( v4 INT , v3 INT UNIQUE , v2 INT , v1 INT UNIQUE ) ; >> CREATE OR REPLACE RULE v1 AS ON INSERT TO v0 DO INSTEAD NOTIFY COMPRESS= ION >> ; >> WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) DELETE FROM v0 WHERE v3 =3D = - - - >> - 48 ; > Seems the Query from RewriteRule->actions may have a NULL jointree, and > that triggers the SEGV in replace_empty_jointree(). I'm inclined to think we have to reject cases like this. In HEAD, replace_empty_jointree is the first thing to crash, but if you try it in back branches it crashes someplace else. Even if we patched all the planner issues, there's no way for the executor to handle this, because it has no provisions for a utility statement as part of a plan tree. Conceivably the NOTIFY could be removed from the query altogether and then executed as a separate top-level command, but I'm not sure that would have desirable semantics. We do already reject some related cases: regression=3D# WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) SELECT * FROM v2= ; ERROR: WITH query "v2" does not have a RETURNING clause LINE 1: WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) SELECT * FROM v2; ^ regression=3D# WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) returning * ) SELE= CT * FROM v2; ERROR: cannot perform INSERT RETURNING on relation "v0" HINT: You need an unconditional ON INSERT DO INSTEAD rule with a RETURNIN= G clause. Also, if you make it an ALSO not INSTEAD rule: regression=3D# CREATE OR REPLACE RULE v1 AS ON INSERT TO v0 DO also NOTIFY= COMPRESSION; CREATE RULE regression=3D# WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) DELETE FROM v0 W= HERE v3 =3D - - - regression-# 48; ERROR: DO ALSO rules are not supported for data-modifying statements in W= ITH So it feels to me like this is just a missed case. We don't really support any cases involving a rule-added NOTIFY in WITH. regards, tom lane