From: | Oleg Jurtšenko <oleg(at)fts(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Oleg Jurtšenko <oleg(dot)jurtsenko(at)fts(dot)ee>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5235: Segmentation fault under high load through JDBC |
Date: | 2010-01-14 20:22:53 |
Message-ID: | 4B4F7D1D.2080301@fts.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
After upgrading to the latest patch level: PostgreSQL 8.4.2 on
i386-portbld-freebsd8.0
I have got a different core dump
(gdb) bt
#0 0x328b1068 in malloc () from /lib/libc.so.7
#1 0x082f1be9 in load_tzoffsets ()
#2 0x080aa5ef in btrescan ()
#3 0x082db80c in FunctionCall2 ()
#4 0x080a4c15 in index_rescan ()
#5 0x080a44a2 in index_getprocid ()
#6 0x080aa662 in btgetbitmap ()
#7 0x082db759 in FunctionCall3 ()
#8 0x080a4f03 in index_endscan ()
#9 0x080a4f84 in index_insert ()
#10 0x08193881 in ExecIndexRestrPos ()
#11 0x34f14af8 in ?? ()
#12 0x37715f40 in ?? ()
#13 0x00000002 in ?? ()
#14 0x37da5e58 in ?? ()
#15 0x37da51f8 in ?? ()
#16 0x37da51fc in ?? ()
#17 0x37da5200 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000100 in ?? ()
#21 0x355a5c88 in ?? ()
#22 0x00000002 in ?? ()
#23 0x00000000 in ?? ()
#24 0xbfa00608 in ?? ()
#25 0x0818382b in ExecInitNode ()
which gave me an idea to tune "max_stack_depth". I increased it four
times from 2MB to 8MB and tried to run my test query: "select
instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
Execution was successful without segfault, but it took 25 seconds to get
a result.
Regards, Oleg
Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>
>> Still, even though the code is preposterous, the result shouldn't be a
>> segfault. I wasn't able to reproduce one myself (using 8.3.7 on
>> freebsd 7.2) however.
>>
>
> Yeah, for me it also recurses till the exception is hit, and then
> processes that successfully. This is effectively identical to a case
> in the standard regression tests, which also intentionally recurses
> till stack overflow. Since we have FreeBSD machines in the buildfarm,
> it is reasonably safe to conclude that this isn't a generic FreeBSD
> bug. I suspect the OP has used some unusual configure/build option
> or linked in some nonstandard code that is causing the available
> stack space to change unexpectedly.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Bunce | 2010-01-14 20:45:06 | Re: Termination When Switching between PL/Perl and PL/PerlU |
Previous Message | Justin Pitts | 2010-01-14 19:03:45 | Re: BUG #5269: postgres backend terminates with SIGSEGV |