From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | Андрей Репко <repko(at)sart(dot)must-ipra(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Server process exited with unexpected status 128. |
Date: | 2005-09-26 15:01:17 |
Message-ID: | 28493.1127746877@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
>> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
>>> max_stack_depth = 65536 # min 100, size in KB
>>
>> Hmm, maybe this is the problem. Are we sure Windows will
>> allow a 64M stack?
> Looks like we used 4MB in the backend by default:
> http://archives.postgresql.org/pgsql-committers/2005-01/msg00386.php
D'oh. Well, at the very least we have a documentation issue here.
Is it sensible to try to prevent people from raising the GUC variable
higher than the platform will allow? It seems we can know the limit on
Windows, but on most other platforms I don't think there's any good way
to find it out. (Which is why max_stack_depth is a SUSET variable ---
you're assumed to know what you are doing if you change it.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-09-26 15:04:13 | Re: roundoff problem in time datatype |
Previous Message | Dave Page | 2005-09-26 14:54:28 | Re: Server process exited with unexpected status 128. |