Re: Infinite loop in transformExpr() - Mailing list pgsql-general

From Fernando Schapachnik
Subject Re: Infinite loop in transformExpr()
Date
Msg-id 20070222125747.GA1214@bal740r0.mecon.gov.ar
Whole thread Raw
In response to Re: Infinite loop in transformExpr()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Infinite loop in transformExpr()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
En un mensaje anterior, Tom Lane escribió:
> Fernando Schapachnik <fschapachnik@mecon.gov.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:
SELECT ...
FROM
    (SELECT ... FROM 3 tables
    WHERE join condition AND
        int_key IN (enumeration of aprox. 16000 values here)
    GROUP BY ...)
LEFT OUTER JOIN join condition GROUP BY ...;

(I can provide a more specific version if needed, but look below.)

A couple of strange things.

The query is executed in production via pgperl in a (FreeBSD 5.x)
server where:

# limit stacksize
stacksize    65536 kbytes
# psql -U pgsql template1 -c 'SHOW max_stack_depth'
 max_stack_depth
-----------------
 2048

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.

On a testing environment, however, setting max_stack_depth to 16000,
it efectively dumps core. The strange thing is, that while trying to
trim down the query, now I'm stuck with:

Fatal error 'Cannot allocate red zone for initial thread' at line 343
in file /usr/src/lib/libpthread/thread/thr_init.c (errno = 12)

(ie, the server works, I just can't get the original error again, not
even after restart or full/freeze vacuum).

The backtrace now gives:

(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 ()
#14 0x081f9f46 in fmgr_info_cxt ()
#15 0x081f9d62 in fmgr_info_cxt ()
#16 0x0811a0dc in init_fcache ()
#17 0x0811a742 in ExecMakeTableFunctionResult ()
#18 0x08125e67 in ExecReScanNestLoop ()
#19 0x0811db75 in ExecScan ()
#20 0x08125ee3 in ExecFunctionScan ()
#21 0x08119061 in ExecProcNode ()
#22 0x08126b8f in ExecSort ()
#23 0x081190c0 in ExecProcNode ()
#24 0x081251f3 in ExecMergeJoin ()
#25 0x08119087 in ExecProcNode ()
#26 0x08126b8f in ExecSort ()
#27 0x081190c0 in ExecProcNode ()
#28 0x08120f5c in ExecAgg ()
#29 0x08120ed5 in ExecAgg ()
#30 0x081190e6 in ExecProcNode ()
#31 0x08117b10 in ExecEndPlan ()
#32 0x08116fb0 in ExecutorRun ()
#33 0x08191f9d in PortalRun ()
#34 0x08191ccc in PortalRun ()
#35 0x0818e259 in pg_plan_queries ()
#36 0x08190dad in PostgresMain ()
#37 0x0816e41c in ClosePostmasterPorts ()
#38 0x0816dc13 in ClosePostmasterPorts ()
#39 0x0816bf07 in PostmasterMain ()
#40 0x0816b875 in PostmasterMain ()
#41 0x08133a0f in main ()


Thanks.

Fernando.

pgsql-general by date:

Previous
From: Russ Brown
Date:
Subject: Re: postgresql vs mysql
Next
From: "Joris Dobbelsteen"
Date:
Subject: Re: complex referential integrity constraints