From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Niklas Hambüchen <mail(at)nh2(dot)me>, pgsql-bugs(at)lists(dot)postgresql(dot)org, ruben(at)benaco(dot)com, Niklas Hambüchen <niklas(at)benaco(dot)com> |
Subject: | Re: "memory exhausted" in query parser/simplifier for many nested parentheses |
Date: | 2024-12-13 16:08:38 |
Message-ID: | 1073817.1734106118@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tomas Vondra <tomas(at)vondra(dot)me> 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 <https://www.postgresql.org/
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Niklas Hambüchen | 2024-12-13 17:06:43 | Re: "memory exhausted" in query parser/simplifier for many nested parentheses |
Previous Message | Tomas Vondra | 2024-12-13 15:11:00 | Re: "memory exhausted" in query parser/simplifier for many nested parentheses |