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) unlimited
data seg size (kbytes, -d) 524288
stack size (kbytes, -s) 65536
core file size (512-blocks, -c) unlimited
max memory size (kbytes, -m) unlimited
locked memory (kbytes, -l) unlimited
max user processes (-u) 4986
open files (-n) 9972
virtual mem size (kbytes, -v) unlimited
swap limit (kbytes, -w) unlimited
sbsize (bytes, -b) unlimited
pseudo-terminals (-p) unlimited
Output of "SHOW max_stack_depth;"
postgres=# SHOW max_stack_depth;
max_stack_depth
-----------------
2MB
(1 row)
I tried to execute "select instr(ad_parent_tree(?,?),'|'||'?'||'|') AS
isItsOwnChild from dual;" query with psql terminal and got segmentation
fault as well.
The most interesting thing is that this function makes segmentation
fault also on FreeBSD 7.2 with Postgresql-8.3.7.
Consequentially, both Postgresql-8.3.7 and Postresql-8.4.1 are affected.
Oleg.
Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
2009/12/8 Oleg Jurtšenko <oleg.jurtse...@fts.ee>:
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 for max stack depth set
to something very small. See:
http://www.postgresql.org/docs/current/interactive/runtime-config-resource.html#GUC-MAX-STACK-DEPTH
You can do "SHOW max_stack_depth;" to confirm the setting for that
parameter. But I'm not quite sure how to check what value is being
applied to PG. Sounds like it's smaller than 2MB, though. You may be
able to reduce max_stack_depth to prevent the crash, but then you'll
get an error instead.
The weird thing about this is that recent versions of PG try to adjust
max_stack_depth automatically. The only ways I can see for that to
fail is if
(1) the platform hasn't got getrlimit(RLIMIT_STACK), or
(2) the effective stack rlimit is so tiny Postgres doesn't believe it,
which looks to be anything under 100KB.
The claim in the docs that the default value is 2MB is a vast
oversimplification of reality, so I'd be interested to know what "show
max_stack_depth" actually reports. It'd also be useful to run
"ulimit -a" in the context in which the postmaster is normally started
(that's NOT your interactive shell session, usually --- try adding
that to the postmaster start script).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
