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 1tM8Dk-0021YZ-Nc for pgsql-bugs@arkaria.postgresql.org; Fri, 13 Dec 2024 16:08:52 +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 1tM8Dh-008VgD-LN for pgsql-bugs@arkaria.postgresql.org; Fri, 13 Dec 2024 16:08:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tM8Dh-008Vg4-CI for pgsql-bugs@lists.postgresql.org; Fri, 13 Dec 2024 16:08:50 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tM8Db-002fVM-63 for pgsql-bugs@lists.postgresql.org; Fri, 13 Dec 2024 16:08:50 +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 4BDG8c3r1073818; Fri, 13 Dec 2024 11:08:38 -0500 From: Tom Lane To: Tomas Vondra cc: Greg Sabino Mullane , =?UTF-8?Q?Niklas_Hamb=C3=BCche?= =?UTF-8?Q?n?= , 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 Tomas Vondra message dated "Fri, 13 Dec 2024 16:11:00 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1073816.1734106118.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 13 Dec 2024 11:08:38 -0500 Message-ID: <1073817.1734106118@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tomas Vondra writes: > On 12/13/24 15:44, Greg Sabino Mullane wrote: >> Documentation patches are always welcome. Perhaps at https:// >> www.postgresql.org/docs/current/limits.html > docs/current/limits.html> ? > FWIW I don't think it's practical to document such limits in detail. Yeah. To take the current example: 1. The grammar nesting limit is imposed by bison, not by us, and it would be odd for us to be the ones to document it. We don't even know whether it's the same across all versions of bison. 2. The stack-overflow limit during optimization is going to manifest at some ridiculously platform-dependent depth. It'll depend on max_stack_depth to begin with, and then the actual number of stack frames that fit into that will depend on a huge number of factors, and probably will change in every PG release. The best the documentation could possibly do is to mention that there's a limit, which seems unhelpful. > Everyone knows the limits exist, and there's a lot of them This. regards, tom lane