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
Andrew Gierth 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 effectiv
> "Andrew" == Andrew Gierth writes:
Andrew> What are the definitions of your instr() and ad_parent_tree()
Andrew> functions?
Well, there's so much wrong with that ad_parent_tree function - it's
always going to recurse infinitely (with a new subxact per recursion
level, even) regardless of
Stefan Kaltenbrunner writes:
> I vaguely recall issues in the past with linking of postgresql (or PLs
> that require it) against libc_r causing some rather small stack limits
> being imposed under some circumstances but I don't recall the details
> any more...
Yeah, we've seen cases where libc
Andrew Gierth wrote:
"Robert" == Robert Haas writes:
Robert> How about (3) getrlimit(RLIMIT_STACK) lies through its teeth,
Robert> by ignoring the existence of another and lower limit imposed
Robert> elsewhere?
Robert> A little Googling seems to reveal that FreeBSD has a
Robert> paramete
Functions are attached
Oleg
Andrew Gierth wrote:
"Oleg" == Oleg Jurtšenko writes:
Oleg> I tried to execute "select instr(ad_parent_tree(?,?),'|'||'?'||'|') AS
Oleg> isItsOwnChild from dual;" query with psql terminal and got
Oleg> segmentation fault as well.
Oleg> The most i
> "Oleg" == Oleg Jurtšenko writes:
Oleg> I tried to execute "select instr(ad_parent_tree(?,?),'|'||'?'||'|') AS
Oleg> isItsOwnChild from dual;" query with psql terminal and got
Oleg> segmentation fault as well.
Oleg> The most interesting thing is that this function makes segmentation
Ol
> "Robert" == Robert Haas writes:
Robert> How about (3) getrlimit(RLIMIT_STACK) lies through its teeth,
Robert> by ignoring the existence of another and lower limit imposed
Robert> elsewhere?
Robert> A little Googling seems to reveal that FreeBSD has a
Robert> parameter called MAXSSIZ (
On Tue, Dec 8, 2009 at 11:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2009/12/8 Oleg Jurtšenko :
>>> You are right, it crushes on following statement: "select
>>> instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
>>>
>>> max_stack_depth is commented out, I think it has the d
I'm not sure about the theory about recursion and infinity loop. I have
tested different versions of Postgres and FreeBSD. Please take a look on
results below.
Well, output of "ulimit -a":
$ ulimit -a
cpu time (seconds, -t) unlimited
file size (512-blocks, -f) unlimit
> Recursion within PL/PgSQL?
er ... sorry for stating the belated and obvious. I was dropped from the
CC on the other branch of this thread so it wasn't hitting my INBOX and
didn't realise it'd carried on until I saw it in my Pg list folder.
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (
(resending with list cc'd)
Oleg Jurtšenko wrote:
> Core dump file are available here:
>
> www.fts.ee/pgsqldebug.tgz - with loging enabled
Well, it certainly looks recursive:
> #0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70, size=16)
> at mcxt.c:559
> #1 0x081bfc16 in Exec
Robert Haas writes:
> 2009/12/8 Oleg Jurtšenko :
>> You are right, it crushes on following statement: "select
>> instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
>>
>> max_stack_depth is commented out, I think it has the default value:
>> #max_stack_depth = 2MB
> Well, my gue
2009/12/8 Oleg Jurtšenko :
> You are right, it crushes on following statement: "select
> instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
>
> max_stack_depth is commented out, I think it has the default value:
> #max_stack_depth = 2MB
Well, my guess is you have your kernel limit
You are right, it crushes on following statement: "select
instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
max_stack_depth is commented out, I think it has the default value:
#max_stack_depth = 2MB
I'm attaching related functions.
Oleg
Robert Haas wrote:
2009/12/8 Oleg Ju
2009/12/8 Oleg Jurtšenko :
> Once more:
>
> http://www.fts.ee/pgsqldebug.tgz - with loging enabled
> http://www.ftse.ee/pg_core.tar.bzip2 - full core dump
It looks like you've got a pl/pgsql function that called itself
recursively 1417 times before running out of stack space. What do you
have max
Once more:
http://www.fts.ee/pgsqldebug.tgz
- with loging enabled
http://www.ftse.ee/pg_core.tar.bzip2
- full core dump
Robert Haas wrote:
2009/12/8 Oleg Jurtšenko :
Both files are there.
Both files are where? I don't see an attachment or a link.
...Robert
Both files are there.
Oleg.
Robert Haas wrote:
2009/12/8 Oleg Jurtšenko :
This the end of core dump. It is 8.3M bzip-ed. I can provide it on the
request.
I think maybe the beginning would be more useful than the end.
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
2009/12/8 Oleg Jurtšenko :
> Both files are there.
Both files are where? I don't see an attachment or a link.
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
2009/12/8 Oleg Jurtšenko :
> This the end of core dump. It is 8.3M bzip-ed. I can provide it on the
> request.
I think maybe the beginning would be more useful than the end.
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://ww
This the end of core dump. It is 8.3M bzip-ed. I can provide it on the
request.
I'm trying to compile Openbravo ERP application. There is no
C/Perl/Python functions.
My investigations show that pgsql catches segmentation fault on some|
||ported Oracle PLSQL function|:
Query in the source code is
On 8/12/2009 8:09 AM, Tom Lane wrote:
"Oleg Yurchenko" writes:
Program terminated with signal 11, Segmentation fault.
#0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70,
size=16) at mcxt.c:559
559 mcxt.c: No such file or directory.
in mcxt.c
[New Thread 28b01140 (L
"Oleg Yurchenko" writes:
> Program terminated with signal 11, Segmentation fault.
> #0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70,
> size=16) at mcxt.c:559
> 559 mcxt.c: No such file or directory.
> in mcxt.c
> [New Thread 28b01140 (LWP 100115)]
> #(gdb)bt
> #141
The following bug has been logged online:
Bug reference: 5235
Logged by: Oleg Yurchenko
Email address: o...@fts.ee
PostgreSQL version: 8.4.1
Operating system: FreeBSD 8.0-RELEASE #0 Generic kernel i386
Description:Segmentation fault under high load through JDBC
Detail
24 matches
Mail list logo
