Re: Server process exited with unexpected status 128.
От | Dave Page |
---|---|
Тема | Re: Server process exited with unexpected status 128. |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E4CC2ECB@ratbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Server process exited with unexpected status 128. (Андрей Репко<repko@sart.must-ipra.com>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 26 September 2005 16:01 > To: Dave Page > Cc: Андрей Репко; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Server process exited with unexpected > status 128. > > "Dave Page" <dpage@vale-housing.co.uk> writes: > >> [mailto:pgsql-hackers-owner@postgresql.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 limitis purely down to the data type. Regards, Dave
В списке pgsql-hackers по дате отправления: