Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tMDkC-002lFq-F2 for pgsql-bugs@arkaria.postgresql.org; Fri, 13 Dec 2024 22:02:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tMDk9-00Cx5b-RP for pgsql-bugs@arkaria.postgresql.org; Fri, 13 Dec 2024 22:02:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tMDk9-00Cx5R-Ii for pgsql-bugs@lists.postgresql.org; Fri, 13 Dec 2024 22:02:42 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tMDk4-002gzc-8q for pgsql-bugs@lists.postgresql.org; Fri, 13 Dec 2024 22:02:41 +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 4BDM2WY61258246; Fri, 13 Dec 2024 17:02:32 -0500 From: Tom Lane To: "David G. Johnston" cc: =?UTF-8?Q?Niklas_Hamb=C3=BCchen?= , pgsql-bugs@lists.postgresql.org, ruben@benaco.com, =?UTF-8?Q?Niklas_Hamb=C3=BCchen?= Subject: Re: "memory exhausted" in query parser/simplifier for many nested parentheses In-reply-to: References: <161892c0-65fc-42a6-8af9-b098879decd4@nh2.me> <654489.1734019548@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Fri, 13 Dec 2024 10:43:03 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1258244.1734127352.1@sss.pgh.pa.us> Date: Fri, 13 Dec 2024 17:02:32 -0500 Message-ID: <1258245.1734127352@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > I don't disagree with the premise that such hard-coded limits are > undesirable but they also aren't always worth getting rid of, especially if > they are inherited from an upstream dependency. Having said all that ... I think there is a case here for raising the core parser's YYMAXDEPTH, which would be a trivial matter of inserting a #define for it. Bison's default value of 10000 was probably set decades ago for much smaller hardware. If I'm computing it right, the space consumed per stack entry in PG is 22 bytes (on 64-bit hardware), so that that limit corresponds to only 220KB in stack, a fairly negligible number. We could make it 10 or 100 times larger without anyone noticing --- especially since this is the upper limit for resizing the stack, not the amount of space used to parse simple inputs. That would get us to a point where expression complexity would almost always be limited by max_stack_depth, which the user has control over. In theory we could make the limit as high as around 45M stack levels, which would approach palloc's 1GB chunk limit. But I can't foresee a reason to let the parser stack get anywhere near that big. If you wrote millions of unmatched left parentheses, you're just trying to cause trouble. So I'd vote for going to 100K or 1M. regards, tom lane