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
depthlimit 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
