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 1noNSR-0004Uq-I8 for pgsql-bugs@arkaria.postgresql.org; Tue, 10 May 2022 10:51:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1noNSO-0003F0-GK for pgsql-bugs@arkaria.postgresql.org; Tue, 10 May 2022 10:51:08 +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 1noNSN-0003ET-Fy for pgsql-bugs@lists.postgresql.org; Tue, 10 May 2022 10:51:08 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1noNSH-000232-Gw for pgsql-bugs@lists.postgresql.org; Tue, 10 May 2022 10:51:06 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0E62E5C0100; Tue, 10 May 2022 06:51:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 10 May 2022 06:51:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1652179860; x=1652266260; bh=XhfOOCuVcb6D8jj3ryfJpK52O9Nu+Bk5nQH 3V7pyfCw=; b=iOoCe3JNTF2gNSXQ3XYpvwBIk7liQ7xiCZbHcEl6GzX3eIjG+8E jPkgcij8oMBsW47OliAMLsJ8qhtGGm+uyKEKflv1LY1dXOyXYUMV8a+HQ1/ADvG5 LFwt9kAwtpqACFk8RtAlw2hqglLS1P8kyxEeV5BazktrYAN2Y4GfEQ7bLelY9fOM W8qQTloRpCB5XKRysCfs4F7DBZVqtcBoUDlQaHryjsnsjO0lM3yvgNdSf0lGHvV+ Ibfal5Na2Gvau+Bbqoygg5KVjza+PrTyylGwGngW9BjQhQCZHNAqz+is+gm680rB MV2U5ZBkKl2yB9EgDXHUBtvax74FWcdasTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgedugddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggugfgjsehtkeertd dttdejnecuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvges rghlvhhhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpedujeevjeffjeevud dutedvkeeiueeitddvieelfeekveejudefgeeuvdejhfeuleenucffohhmrghinhepvghn thgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 10 May 2022 06:50:59 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C8C9C2A0F7C; Tue, 10 May 2022 12:50:57 +0200 (CEST) Date: Tue, 10 May 2022 12:50:57 +0200 From: Alvaro Herrera To: krking@zju.edu.cn, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17480: Assertion failure in parse_relation.c Message-ID: <202205101050.sepjyffoevsy@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17480-1c9d73565bb28e90@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-May-10, PG Bug reporting form wrote: > Testcase: > ``` > CREATE TABLE v0 ( v3 INT , v2 VARCHAR , v1 INT , UNIQUE ( v1 , v3 ) ) ; > VALUES ( - - -128 , - - - - 127 , NULL ) ; > SELECT FROM LATERAL XMLTABLE ( ROW ( ) PASSING NULL BY VALUE COLUMNS v1 > TIMESTAMP WITHOUT TIME ZONE ARRAY ) AS DELETE ( v3 , v3 , v2 , v3 , v1 , > FIRST , v1 , FLOAT , INT , v2 , v3 , VERSION , v2 , FLOAT , INT , v1 , NO , > ROW , v3 , v2 ) ORDER BY v2 , v2 ; > ``` Hmm, were you using a fuzzer to generate this query? It would sure be useful to have it process some more and see what other crashes it discovers. Your example can be reduced to this, which already crashes the server: SELECT * FROM XMLTABLE (ROW () passing null COLUMNS v1 TIMESTAMP, v2 int) AS f (v1, v2, v3); and with this it is clear that the problem is that the alias list is too long for the COLUMNS specification of the XMLTABLE function. This can be avoided by throwing an error: diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index 7465919044..6c817a9c55 100644 --- a/src/backend/parser/parse_relation.c +++ b/src/backend/parser/parse_relation.c @@ -2001,6 +2001,12 @@ addRangeTableEntryForTableFunc(ParseState *pstate, eref->colnames = list_concat(eref->colnames, list_copy_tail(tf->colnames, numaliases)); + if (numaliases > list_length(tf->colnames)) + ereport(ERROR, + (errcode(ERRCODE_SYNTAX_ERROR), + errmsg("%s function has %d columns available but %d columns specified", + "XMLTABLE", list_length(tf->colnames), numaliases))); + rte->eref = eref; /* (Obviously, no regression test changes output after this patch.) This mirrors what happens when you give too many aliases to tables or other things. (In pg15 and up, it needs to be aware of JSON_TABLE too. I made this on pg14.) -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Uno puede defenderse de los ataques; contra los elogios se esta indefenso"