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

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(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.
>
> 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
>