On Tue, Jul 5, 2016 at 11:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@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