Re: BUG #19108: Stack overflow duting query parse
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Zhidenkov <pensnarik@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-bugs@lists.postgresql.org
Date: 2025-11-10T17:35:07Z
Lists: pgsql-bugs
Andrey Zhidenkov <pensnarik@gmail.com> writes: >> Could you at least provide a not-mangled-to-the-point-of-incorrectness > version of the query? > Sure, here it is: > ... Thanks. I made this into a full-size test case by just duplicating one of the lines 1000 times. (The parser is not going to notice whether the values are equal, though possibly we'd detect that later.) We do produce a deeply nested boolean OR tree from this WHERE condition, but I don't see any indication that that should be a problem. It works just fine for me at the default max_stack_depth, and even down to max_stack_depth = '300kB', and below that I get a clean failure: ERROR: stack depth limit exceeded HINT: Increase the configuration parameter "max_stack_depth" (currently 200kB), after ensuring the platform's stack depth limit is adequate. So I seriously doubt that Postgres is doing anything wrong. It looks to me like your machine is/was under serious memory pressure and that was causing the kernel to do strange things like refuse to expand the stack as much as was promised by getrlimit(). You might want to compare the swap and OOM-killer configuration on the problematic machine to ones that are okay. Another, probably more far-fetched theory is some kind of hardware issue on that machine --- bad RAM or the like. regards, tom lane