On Tue, Dec 8, 2009 at 11:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 2009/12/8 Oleg Jurtšenko <oleg.jurtse...@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.
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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
