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 1muFQA-0003Qv-Aw for pgsql-bugs@arkaria.postgresql.org; Mon, 06 Dec 2021 14:56:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1muFQ7-0005Tf-RH for pgsql-bugs@arkaria.postgresql.org; Mon, 06 Dec 2021 14:56:47 +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 1muFQ7-0005Sz-Ir for pgsql-bugs@lists.postgresql.org; Mon, 06 Dec 2021 14:56:47 +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 1muFQ4-00025u-Po for pgsql-bugs@lists.postgresql.org; Mon, 06 Dec 2021 14:56:47 +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 1B6EueXg3048016; Mon, 6 Dec 2021 09:56:40 -0500 From: Tom Lane To: 253540651@qq.com cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut Subject: Re: BUG #17318: ERROR: AddressSanitizer: SEGV on unknown address in optimizer In-reply-to: <17318-2eb65a3a611d2368@postgresql.org> References: <17318-2eb65a3a611d2368@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Mon, 06 Dec 2021 06:40:39 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3048014.1638802600.1@sss.pgh.pa.us> Date: Mon, 06 Dec 2021 09:56:40 -0500 Message-ID: <3048015.1638802600@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > WITH RECURSIVE x ( x ) AS ( SELECT 1 UNION ALL SELECT x FROM LATERAL ( ( > SELECT * FROM ( ( SELECT 4 AS x ) UNION ALL ( SELECT 5 AS x ) ) AS x WHERE x > BETWEEN 1 AND 2 AND x < ( SELECT 3 GROUP BY DISTINCT ROLLUP ( x , x ) , > ROLLUP ( x , x ) ) ) UNION ALL ( SELECT ( SELECT x LIMIT 1 ) FROM x OFFSET 0 > LIMIT 5 ) ) AS x GROUP BY ROLLUP ( ( x , x , x ) , ( ( SELECT TRIM ( > TRAILING ' ' FROM SUBSTRING ( VERSION ( ) FROM '^[^0-9]*' ) ) WHERE ( x IS > NOT NULL ) ) , x ) ) ) CYCLE x SET BOOLEAN USING VALUES SELECT FROM x GROUP > BY DISTINCT CUBE ( x , x , x ) ; I simplified this to WITH RECURSIVE x ( x ) AS ( SELECT 1 UNION ALL SELECT x FROM ( SELECT 4 AS x UNION ALL SELECT x FROM x ) AS x ) CYCLE x SET b USING v SELECT * FROM x ; and now I'm not sure whether to consider this an optimizer bug or failure to detect an unsupported case. Our SELECT ref page says Both the SEARCH and the CYCLE clause are only valid for recursive WITH queries. The with_query must be a UNION (or UNION ALL) of two SELECT (or equivalent) commands (no nested UNIONs). This WITH query sure looks like nested UNIONs to me, so either that restriction is stated incorrectly, or it's being enforced inadequately. If the former, we have an optimizer problem. regards, tom lane