Robert Haas <robertmhaas@gmail.com> writes:
> 2009/12/8 Oleg Jurtšenko <oleg.jurtsenko@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
