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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 2009/12/8 Oleg Jurtenko <oleg(dot)jurtsenko(at)fts(dot)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