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
Subject: Re: BUG #19108: Stack overflow duting query parse
In-reply-to: 
 <CAN=gQ4DtU6fPEttn8KW5N2tUXYqHUNuPott_Ex7GCO7VqMsMxg@mail.gmail.com>
References: <19108-13b9dd7a2d30a9cc@postgresql.org>
 <e7c2340a-3a01-4095-b606-0e8e77384084@iki.fi>
 <CAN=gQ4DQKP+Hb+a57SKE9_g2_Utumfccacc9pnw9Okpr6RwVrQ@mail.gmail.com>
 <1879801.1762790568@sss.pgh.pa.us>
 <CAN=gQ4DtU6fPEttn8KW5N2tUXYqHUNuPott_Ex7GCO7VqMsMxg@mail.gmail.com>
Comments: In-reply-to Andrey Zhidenkov <pensnarik@gmail.com>
	message dated "Mon, 10 Nov 2025 19:12:40 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1889905.1762796107.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Nov 2025 12:35:07 -0500
Message-ID: <1889906.1762796107@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1889906.1762796107%40sss.pgh.pa.us>
Precedence: bulk

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 =3D '300kB', and below that I get a
clean failure:

ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth" (currently 2=
00kB), 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