Re: Infinite loop in transformExpr()

Fernando Schapachnik <fernando(at)mecon(dot)gov(dot)ar> writes:
> En un mensaje anterior, Tom Lane escribi:
>> Fernando Schapachnik <fschapachnik(at)mecon(dot)gov(dot)ar> writes:
>>> I've stumbled upon what seems to be a core-dumping infinite recursion
>>> in transformExpr(), on 8.1.6.
>>
>> A test case would help.

> The culprit query looks like:
> WHERE join condition AND
> int_key IN (enumeration of aprox. 16000 values here)

PG versions before 8.2 don't handle very long IN lists particularly
well. This query will take a fair amount of stack space to parse, not
to mention an unreasonably long time to plan. (You should consider
putting the 16000 values in a temp table and doing a join, instead.)

> Running the query in this scenario (reasonably) gives:
> ERROR: stack depth limit exceeded
> HINT: Increase the configuration parameter "max_stack_depth".
> So I'm unsure why it explodes in production.

Most likely, the production machine has a kernel-enforced stack limit
setting that is less than what "max_stack_depth" claims. Up till recently
(8.2 I think), we didn't make any effort to verify that "max_stack_depth"
was set to a sane value. If it's too high you will get crashes rather
than "stack depth limit exceeded", because overrunning the kernel limit
is typically treated as a SIGSEGV.

> (gdb) bt
> #0 0x284eb37b in kill () from /lib/libc.so.5
> #1 0x284e0422 in raise () from /lib/libc.so.5
> #2 0x28552c1b in abort () from /lib/libc.so.5
> #3 0x290b6a7c in pthread_testcancel () from /usr/lib/libpthread.so.1
> #4 0x290b3067 in pthread_setconcurrency () from
> /usr/lib/libpthread.so.1
> #5 0x290b2e87 in pthread_setconcurrency () from
> /usr/lib/libpthread.so.1
> #6 0x290b627a in pthread_testcancel () from /usr/lib/libpthread.so.1
> #7 0x290b740a in __error () from /usr/lib/libpthread.so.1
> #8 0x2909e7ae in ?? () from /usr/lib/libpthread.so.1
> #9 0x282a5845 in find_symdef () from /libexec/ld-elf.so.1
> #10 0x282a61aa in dlopen () from /libexec/ld-elf.so.1
> #11 0x08164d38 in BSD44_derived_dlopen ()
> #12 0x081f9550 in load_external_function ()
> #13 0x081fa06c in fmgr_info_cxt ()

Hm. It would appear that you are loading some custom code that sucks
pthread support into the backend. This is generally a bad idea in any
case, as the backend code is not designed for threaded operation. But
the reason it seems relevant is that thread support often causes a
decrease in the effective stack limit (because it's slicing up the stack
area for use by multiple threads). I'd suggest trying to fix the link
dependencies of your code to avoid sucking in libpthread.

regards, tom lane