On Tue, Jul 5, 2016 at 11:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@mit.edu> writes: >> Poking at NetBSD kernel source it looks like the default ulimit -s >> depends on the architecture and ranges from 512k to 16M. Postgres >> insists on max_stack_depth being STACK_DEPTH_SLOP -- ie 512kB -- less >> than the ulimit setting making it impossible to start up on >> architectures with a default of 512kB without raising the ulimit. > >> If we could just lower it to 384kB then Postgres would start up but I >> wonder if we should just use MIN(stack_rlimit/2, STACK >> _DEPTH_SLOP) so that there's always a setting of max_stack_depth that >> would allow Postgres to start. > > I'm pretty nervous about reducing that materially without any > investigation into how much of the slop we actually use. Our assumption > so far has generally been that only recursive routines need to have any > stack depth check; but there are plenty of very deep non-recursive call > paths. I do not think we're doing people any favors by letting them skip > fooling with "ulimit -s" if the result is that their database crashes > under stress. For that matter, even if we were sure we'd produce a > "stack too deep" error rather than crashing, that's still not very nice > if it happens on run-of-the-mill queries.
To me it seems like using anything based on stack_rlimit/2 is pretty risky for the reason that you state, but I also think that not being able to start the database at all on some platforms with small stacks is bad. If I had to guess, I'd bet that most functions in the backend use a few hundred bytes of stack space or less, so that even 100kB of stack space is enough for hundreds of stack frames. If we're putting that kind of depth on the stack without ever checking the stack depth, we deserve what we get. That having been said, it wouldn't surprise me to find that we have functions here and there which put objects that are many kB in size on the stack, making it much easier to overrun the available stack space in only a few frames. It would be nice if there were a tool that you could run over your binaries and have it dump out the names of all functions that create large stack frames, but I don't know of one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers