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
