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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Reviewing freeze map code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: can we optimize STACK_DEPTH_SLOP