Re: "Make" versus effective stack limit in regression tests

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: "Make" versus effective stack limit in regression tests
Date: 2010-11-06 07:21:44
Message-ID: 4CD50208.8000908@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.11.2010 00:39, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2010-11-06 10:42:40 Protecting against unexpected zero-pages: proposal
Previous Message Hitoshi Harada 2010-11-06 07:04:37 Re: SQL/MED estimated time of arrival?