Re: can we optimize STACK_DEPTH_SLOP

Greg Stark <stark(at)mit(dot)edu> writes:
> Searching for info on ia64 turned up this interesting thread:
> https://www.postgresql.org/message-id/21563.1289064886%40sss.pgh.pa.us

Yeah, that's the same one I referenced upthread ;-)

> From that discussion it seems we should probably run these tests with
> -O0 because the stack usage can be substantially higher without
> optimizations. And it doesn't sound like ia64 uses much more *normal*
> stack, just that there's the additional register stack.

> It might not be unreasonable to commit the pmap hack, gather the data
> from the build farm then later add an #ifdef around it. (or just make
> it #ifdef USE_ASSERTIONS which I assume most build farm members are
> running with anyways).

Hmm. The two IA64 critters in the farm are running HPUX, which means
they likely don't have pmap. But I could clean up the hack I used to
gather stack size data on gaur's host and commit it temporarily.
On non-HPUX platforms we could just try system("pmap -x") and see what
happens; as long as we're ignoring the result it shouldn't cause anything
really bad.

I was going to object that this would probably not tell us anything
about the worst-case IA64 stack usage, but I see that neither of those
critters are selecting any optimization, so actually it would.

So, agreed, let's commit some temporary debug code and see what the
buildfarm can teach us. Will go work on that in a bit.

> Alternatively it wouldn't be very hard to use mincore(2) to implement
> it natively. I believe mincore is nonstandard but present in Linux and
> BSD.

Hm, after reading the man page I don't quite see how that would help?
You'd have to already know the mapped stack address range in order to
call the function without getting ENOMEM.

regards, tom lane