Re: BUG #5235: Segmentation fault under high load through JDBC

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