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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: long sql "in" clause crashes server process (8.0 Release)


  • From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
  • To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: <pgsql-hackers-win32(at)postgresql(dot)org>
  • Subject: Re: long sql "in" clause crashes server process (8.0 Release)
  • Date: Mon, 24 Jan 2005 22:16:26 +0100
  • Message-id: <6BCB9D8A16AC4241919521715F4D8BCE4766DC(at)algol(dot)sollentuna(dot)se>

>> Can we increase that setting during the Windows build?  I'd like to
>see
>> it set to 4Mb if possible.
>
>Yes.  Also, if the poster happens to have visual studio 
>installed, there
>is a utility called editbin that allows manually changing a stack (be
>sure to change postgres.exe and postmaster.exe at the least).
>
>The linker switch to do this is:
>
>The Stack Allocations (/STACK:reserve[,commit]) option sets the size of
>the stack in bytes. 
> 

On MingW, you add:
-Wl,--stack=4194304

to get 4Mb stack. At least the value increases in the header. 

And I can confirm that doing this fixes the problem and turns it into
the error message about stack size. (But won't things crash again if I
increase that one? Or will it increase the stack manually then?)

Patch attached.

>> BTW, what's the difference between "stack reserve" and 
>"stack commit"?
>
>Just guessing, but this may have something to do with controlling how
>much of the stack can be swapped out to virtual memory.  I'd suggest
>leaving it alone.

IIRC:
Stack Reserve = Amount of virtual memory used for stack
Stack Commit = Initial/minimal amount of physical memory used for stack

//Magnus

Attachment: stack.patch
Description: stack.patch



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group