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

On Tue, Dec 8, 2009 at 11:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 2009/12/8 Oleg Jurtšenko <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.

How about (3) getrlimit(RLIMIT_STACK) lies through its teeth, by
ignoring the existence of another and lower limit imposed elsewhere?

A little Googling seems to reveal that FreeBSD has a parameter called
MAXSSIZ (and possibly a variant for 64-bit builds). I kind find a lot
of people talking about needing to raise it (for MySQL, among other
things), but I haven't been able to determine for certain what the
default is. Perhaps it is set to a really low value on the OP's
system?

...Robert