On Wed, Sep 1, 2010 at 3:49 PM, Cristian Bittel <cbittel@gmail.com> wrote:
> Maybe the issue, for the momtent, could be avoided modifying the shared heap
> for sessions on Windows. But I don't really have idea how much to increase
> or decrease the values. Try and error? But, inside the opened Windows
> sessions nothing alerts of a heap exaust so could be unpredictable how much
> to change the values until the next PostgreSQL service crash...
> 32-bits: http://support.microsoft.com/kb/184802
>
> There are several reports for another services with the same behavior
> including exit code 128 and a workaround to increase the heap on old Windows
> versions but the Exit Code 128 seems to apply to Windows 2003 Server x64
> also. And seems to be improved in Windows 2008 where heap is not fixed.
> https://fogbugz.bitvise.com/default.asp?WinSSHD.1.12888.2
> http://support.microsoft.com/kb/824422
Given the unpredictability, if this is connected to desktop heap I
don't think it's running out of per-session memory, so much as the
system-wide heap (which, afaict, is fixed at 48MB). That might explain
why a desktop session could affect other sessions.
Is this a terminal server, with lots of interactive users? Can you
check the heap usage using the desktop heap monitor:
http://www.microsoft.com/downloads/details.aspx?familyid=5cfc9b74-97aa-4510-b4b9-b2dc98c8ed8b&displaylang=en
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company