Re: "Make" versus effective stack limit in regression tests
От | Heikki Linnakangas |
---|---|
Тема | Re: "Make" versus effective stack limit in regression tests |
Дата | |
Msg-id | 4CD50208.8000908@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: "Make" versus effective stack limit in regression tests (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 06.11.2010 00:39, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> On 11/05/2010 05:45 PM, Tom Lane wrote: >>> Anyway, what this points up is that we are making a very conservative >>> assumption about what to do when getrlimit() returns RLIM_INFINITY. >>> It does not seem real reasonable to interpret that as 100kB on any >>> modern platform. I'm inclined to interpret it as 4MB, which is the >>> same default stack limit that we use on Windows. > >> +1. > > After looking a bit closer, I think the real problem is that > get_stack_depth_rlimit's API fails to distinguish between "unknown" and > "unlimited". In the first case we ought to have a conservative default, > whereas in the second case not. It's already the case that (a) > max_stack_depth is a SUSET parameter, and (b) for either unknown or > unlimited RLIMIT_STACK, we will let a superuser set whatever value he > wants, and it's on his head whether that value is safe or not. That > part of the behavior seems OK. What's not OK is using the same > built-in default value in both cases. We need to fix it so that > InitializeGUCOptions can tell the difference. If it can, I think the > current default of 2MB is OK --- most people will be fine with that, > and those who aren't can select some other value. Yeah, I bumped into this two years ago but it didn't lead to a patch: http://archives.postgresql.org/pgsql-hackers/2008-07/msg00918.php +1 on choosing 2MB for RLIM_INFINITY. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: