From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: can we optimize STACK_DEPTH_SLOP |
Date: | 2016-07-08 13:49:03 |
Message-ID: | CAM-w4HN8-ZRj4MvVT+ex5VUMzHAFumGUk914QkEyu4x9eSXTtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 8, 2016 at 4:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Based on what I'm seeing so far, really 100K ought to be more than plenty
> of slop for most architectures, but I'm afraid to go there for IA64.
Searching for info on ia64 turned up this interesting thread:
https://www.postgresql.org/message-id/21563.1289064886%40sss.pgh.pa.us
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).
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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-08 14:32:20 | Re: can we optimize STACK_DEPTH_SLOP |
Previous Message | Amit Kapila | 2016-07-08 13:24:41 | Re: Reviewing freeze map code |