Re: can we optimize STACK_DEPTH_SLOP
От | Greg Stark |
---|---|
Тема | Re: can we optimize STACK_DEPTH_SLOP |
Дата | |
Msg-id | CAM-w4HN8-ZRj4MvVT+ex5VUMzHAFumGUk914QkEyu4x9eSXTtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: can we optimize STACK_DEPTH_SLOP (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: can we optimize STACK_DEPTH_SLOP
|
Список | pgsql-hackers |
On Fri, Jul 8, 2016 at 4:46 AM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: