I wrote:
> I think what must be happening is that the kernel is refusing
> to expand our stack any more once we've hit the "ulimit -v" limit.
> This is quite nasty, because it breaks all our assumptions about
> having X amount of stack still available once check_stack_depth
> triggers.
I find this in [1]:
The C language stack growth does an implicit mremap. If you want absolute
guarantees and run close to the edge you MUST mmap your stack for the
largest size you think you will need. For typical stack usage this does
not matter much but it's a corner case if you really really care
Seems like we need to do some more work at startup to enforce that
we have the amount of stack we think we do, if we're on Linux.
regards, tom lane
[1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting