Re: BUG #5235: Segmentation fault under high load through JDBC - Mailing list pgsql-bugs

I'm not sure about the theory about recursion and infinity loop. I have
tested different versions of Postgres and FreeBSD. Please take a look on
results below.

Well, output of "ulimit -a":

$ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  4986
open files                      (-n)  9972
virtual mem size        (kbytes, -v)  unlimited
swap limit              (kbytes, -w)  unlimited
sbsize                   (bytes, -b)  unlimited
pseudo-terminals                (-p)  unlimited

Output of "SHOW max_stack_depth;"

postgres=# SHOW max_stack_depth;max_stack_depth
-----------------2MB
(1 row)

I tried to execute "select instr(ad_parent_tree(?,?),'|'||'?'||'|') AS
isItsOwnChild from dual;" query with psql terminal and got segmentation
fault as well.

The most interesting thing is that this function makes segmentation
fault also on FreeBSD 7.2 with Postgresql-8.3.7.

Consequentially, both Postgresql-8.3.7 and Postresql-8.4.1 are affected.

Oleg.
Tom Lane wrote:
> 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
>