Skip site navigation (1) Skip section navigation (2)

Re: Server process exited with unexpected status 128.

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2005-09-26 15:04:13
Subject: Re: roundoff problem in time datatype
Previous:From: Dave PageDate: 2005-09-26 14:54:28
Subject: Re: Server process exited with unexpected status 128.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group