Re: can we optimize STACK_DEPTH_SLOP

On Tue, Jul 5, 2016 at 8:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Unfortunately the way I did (1) only works on systems with pmap; I'm not
> sure how to make it more portable.

I did a similar(ish) test which is admittedly not as exhaustive as
using pmap. I instrumented check_stack_depth() itself to keep track of
a high water mark (and based on Robert's thought process) to keep
track of the largest increment over the previous checked stack depth.
This doesn't cover any cases where there's no check_stack_depth() call
in the call stack at all (but then if there's no check_stack_depth
call at all it's hard to see how any setting of STACK_DEPTH_SLOP is
necessarily going to help).

I see similar results to you. The regexp test shows:
LOG: disconnection: highest stack depth: 392256 largest stack increment: 35584

And the:
STATEMENT: select infinite_recurse();
LOG: disconnection: highest stack depth: 2097584 largest stack increment: 1936

There were a couple other tests with similar stack increase increments
to the regular expression test:

STATEMENT: alter table atacc2 add constraint foo check (test>0) no inherit;
LOG: disconnection: highest stack depth: 39232 largest stack increment: 34224
STATEMENT: SELECT chr(0);
LOG: disconnection: highest stack depth: 44144 largest stack increment: 34512

But aside from those two the next largest increment between two
success check_stack_depth calls was about 12kB:

STATEMENT: select array_elem_check(121.00);
LOG: disconnection: highest stack depth: 24256 largest stack increment: 12896

This was all on x86_64 too.

--
greg