Re: can we optimize STACK_DEPTH_SLOP

I found out that pmap can give much more fine-grained results than I was
getting before, if you give it the -x flag and then pay attention to the
"dirty" column rather than the "nominal size" column. That gives a
reliable indication of how much stack space the process ever actually
touched, with resolution apparently 4KB on my machine.

I redid my measurements with commit 62c8421e8 applied, and now get results
like this for one run of the standard regression tests:

$ grep '\[ stack \]' postmaster.log | sort -k 4n | uniq -c
137 00007fff0f615000 84 36 36 rw--- [ stack ]
21 00007fff0f615000 84 40 40 rw--- [ stack ]
4 00007fff0f615000 84 44 44 rw--- [ stack ]
20 00007fff0f615000 84 48 48 rw--- [ stack ]
8 00007fff0f615000 84 52 52 rw--- [ stack ]
2 00007fff0f615000 84 56 56 rw--- [ stack ]
10 00007fff0f615000 84 60 60 rw--- [ stack ]
3 00007fff0f615000 84 64 64 rw--- [ stack ]
3 00007fff0f615000 84 68 68 rw--- [ stack ]
2 00007fff0f615000 84 72 72 rw--- [ stack ]
1 00007fff0f612000 96 76 76 rw--- [ stack ]
2 00007fff0f60e000 112 112 112 rw--- [ stack ]
1 00007fff0f5e0000 296 296 296 rw--- [ stack ]
1 00007fff0f427000 2060 2060 2060 rw--- [ stack ]

The rightmost numeric column is the "dirty KB in region" column, and 36KB
is the floor established by the postmaster. (It looks like selecting
timezone is still the largest stack-space hog in that, but it's no longer
enough to make me want to do something about it.) So now we're seeing
some cases that exceed that floor, which is good. regex and errors are
still the outliers, as expected.

Also, I found that on OS X "vmmap -dirty" could produce results comparable
to pmap, so here's the numbers for the same test case on current OS X:

154 Stack 8192K 36K 2
5 Stack 8192K 40K 2
11 Stack 8192K 44K 2
6 Stack 8192K 48K 2
11 Stack 8192K 52K 2
7 Stack 8192K 56K 2
8 Stack 8192K 60K 2
2 Stack 8192K 64K 2
2 Stack 8192K 68K 2
4 Stack 8192K 72K 2
1 Stack 8192K 76K 2
2 Stack 8192K 108K 2
1 Stack 8192K 384K 2
1 Stack 8192K 2056K 2

(The "virtual" stack size seems to always be the same as ulimit -s,
ie 8MB by default, on this platform.) This is good confirmation
that the actual stack consumption is pretty stable across different
compilers, though it looks like OS X's version of clang is a bit
more stack-wasteful for the regex recursion.

Based on these numbers, I'd have no fear of reducing STACK_DEPTH_SLOP
to 256KB on x86_64. It would sure be good to check things on some
other architectures, though ...

regards, tom lane