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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: "Make" versus effective stack limit in regression tests
Date: 2010-11-05 22:39:29
Message-ID: 3656.1288996769@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-11-05 22:49:35 plpgsql execute vs. SELECT ... INTO
Previous Message Hannu Krosing 2010-11-05 22:39:01 Re: Simplifying replication