From: | Fernando Schapachnik <fernando(at)mecon(dot)gov(dot)ar> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Infinite loop in transformExpr() |
Date: | 2007-02-22 12:57:47 |
Message-ID: | 20070222125747.GA1214@bal740r0.mecon.gov.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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:
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Joris Dobbelsteen | 2007-02-22 13:03:02 | Re: complex referential integrity constraints |
Previous Message | Russ Brown | 2007-02-22 12:40:23 | Re: postgresql vs mysql |