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 1oHN0d-0002oN-Vm for pgsql-bugs@arkaria.postgresql.org; Fri, 29 Jul 2022 10:14:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oHN0c-0002Fa-F2 for pgsql-bugs@arkaria.postgresql.org; Fri, 29 Jul 2022 10:14:18 +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 1oHN0c-0002FQ-6V for pgsql-bugs@lists.postgresql.org; Fri, 29 Jul 2022 10:14:18 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHN0Z-0005Ow-IO for pgsql-bugs@lists.postgresql.org; Fri, 29 Jul 2022 10:14:17 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 80D365C007A; Fri, 29 Jul 2022 06:14:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 29 Jul 2022 06:14:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id: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=fm3; t=1659089654; x=1659176054; bh=WL70O+QrhQsNF JOMG8LeKx9FfhzWL/LPslQMUF1+vBk=; b=xx7oN/MokXMYqGKEqO0S3tlace05G y1Wb1LfBleaoo3+UiHRhSa526/edxk4sQQFSsfYi6HoiS2oXCC7RZuucAk+n7F+A bluYmRvSAB7txEM1FBAvlHYWKskOUANttOPJpf9uMxwwQEq/c+J8iyq6F+yVnquW e8QsiiXYqjos9BGpiOi1tKriUAn8+4Tbw85a2gfy3C6ezEWImlChMhWS0bU7NzeA z6RqxlUokWuOVkRoK2K0gzgA0B/u+eK2TLA+CvQ6uPRMGBFXOXDj8SYCFB1Tx1Xn 9Y8D4UO/+c3afAUwZYBvd2Em8N0gDjyqoSL4bgGhHgrWYz+w5LLKrXdXQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvddujedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugfgjgesmhekre ertddtjeenucfhrhhomheptehlvhgrrhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgv segrlhhvhhdrnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnheptedvhfetueeuke efhfefudegfffhhefhvdelffelteekgeegfefhgfegkeejtddunecuffhomhgrihhnpegv nhhtvghrphhrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 29 Jul 2022 06:14:13 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 15AEA376; Fri, 29 Jul 2022 12:14:11 +0200 (CEST) Date: Fri, 29 Jul 2022 12:14:11 +0200 From: Alvaro Herrera To: kyzevan23@mail.ru, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17561: Server crashes on executing row() with very long argument list Message-ID: <20220729101411.7b45rvhlrsgcajjo@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5lkkrvvoycmlmxxx" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17561-80350151b9ad2ad4@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --5lkkrvvoycmlmxxx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2022-Jul-29, PG Bug reporting form wrote: > When executing the following query: > (echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done; > echo "'0',0);"; ) | psql > I got server crash with the following backtrace ... > #5 0x0000557e1694f850 in ExceptionalCondition > (conditionName=conditionName@entry=0x557e169b2e62 "attributeNumber >= 1", > errorType=errorType@entry=0x557e169b0e7f "BadArgument", > fileName=fileName@entry=0x557e169b2d7c "tupdesc.c", > lineNumber=lineNumber@entry=598) at assert.c:69 > #6 0x0000557e1642790a in TupleDescInitEntry > (desc=desc@entry=0x7f42a4c8b050, > attributeNumber=attributeNumber@entry=-32768, > attributeName=attributeName@entry=0x0, oidtypeid=23, typmod=typmod@entry=-1, > attdim=attdim@entry=0) > at tupdesc.c:598 > #7 0x0000557e1664c509 in ExecTypeFromExprList (exprList=0x7f42a7830cf0) at > execTuples.c:2009 Hah, of course. I suppose we'd need something like this ... haven't looked for other problem spots. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ --5lkkrvvoycmlmxxx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="overflow.patch" diff --git a/src/backend/executor/execTuples.c b/src/backend/executor/execTuples.c index 06ac253ea0..798a7e8518 100644 --- a/src/backend/executor/execTuples.c +++ b/src/backend/executor/execTuples.c @@ -2016,6 +2016,12 @@ ExecTypeFromExprList(List *exprList) cur_resno, exprCollation(e)); cur_resno++; + + /* prevent overflow */ + if (cur_resno >= MaxAttrNumber) + ereport(ERROR, + (errcode(ERRCODE_TOO_MANY_COLUMNS), + errmsg("too many attributes"))); } return typeInfo; --5lkkrvvoycmlmxxx--