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

On Tue, Dec 8, 2009 at 11:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 2009/12/8 Oleg Jurt=C5=A1enko <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 =3D 2MB
>
>> Well, my guess is you have your kernel limit for max stack depth set
>> to something very small. =C2=A0See:
>
>> http://www.postgresql.org/docs/current/interactive/runtime-config-resour=
ce.html#GUC-MAX-STACK-DEPTH
>
>> You can do "SHOW max_stack_depth;" to confirm the setting for that
>> parameter. =C2=A0But I'm not quite sure how to check what value is being
>> applied to PG. =C2=A0Sounds like it's smaller than 2MB, though. =C2=A0Yo=
u 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. =C2=A0The 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