> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailtogsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: 26 September 2005 15:47
> To: áÎÄÒÅÊ òÅÐËÏ
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Server process exited with unexpected
> status 128.
>
> [ looking again... ]
>
> =?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?=
> <repko@sart.must-ipra.com> writes:
> > 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...1/msg00386.php

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Dave Page" <dpage@vale-housing.co.uk> writes:
>> [mailtogsql-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...1/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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> 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 have PL/Java users that set a ridiculously high value in
max_stack_depth just to circumvent the check altogether since it breaks
when the executes code using another thread then main (see previous
discussion "stack depth limit exceeded problem" started 9/23 for more info).

If you plan to limit the GUC setting, please, *please*, also provide a
way for PL/Java to switch stack_base. I will write the patch immediately
if you approve.

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org