Re: Server process exited with unexpected status 128.

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:08:47
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4CC2ECB@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 26 September 2005 16:01
> To: Dave Page
> Cc: Андрей Репко; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Server process exited with unexpected
> status 128.
>
> "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.)

I think It's sensible if it's a limit we can find relatively easily. In this case though it sounds like this is not the case.

Perhaps we could issue a warning at startup if the value seems like it might be over the top? I assume the current limit is purely down to the data type.

Regards, Dave

Browse pgsql-hackers by date

  From Date Subject
Next Message Jochem van Dieten 2005-09-26 15:16:41 Re: roundoff problem in time datatype
Previous Message Greg Stark 2005-09-26 15:04:13 Re: roundoff problem in time datatype