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
