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 <http://support.microsoft.com/kb/184802%20>
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 2010/8/31 Bruce Momjian <br...@momjian.us> > Dave Page wrote: > > On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian <br...@momjian.us> wrote: > > > Dave Page wrote: > > >> On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian <br...@momjian.us> > wrote: > > >> > We have already found that exceeding desktop heap might cause a > > >> > CreateProcess to return success but later fail with a return code of > > >> > 128, which causes a server restart. > > >> > > >> That doesn't mean that this is desktop heap exhaustion though - just > > >> that it can cause the same effect. > > > > > > Right, but it is the only possible server crash cause we have come up > > > with so far. > > > > Understood - I'm just unconvinced it's the cause - aside from the > > point I made earlier about heap exhaustion being very predictable and > > reproducible (which this issue apparently is not), when the server is > > run under the SCM, it creates a logon session for that service alone > > which has it's own heap allocation which is entirely independent of > > the allocation used by any interactive logon sessions. > > > > So unless there's a major isolation bug in Windows, any desktop heap > > usage in an interactive session for one user should have zero effect > > on a non-interactive session for another user. > > Well, the only description that we have ever heard that makes sense is > some kind of heap exhaustion, perhaps triggered by a Windows bug that > doesn't properly track heap allocations sometimes. > > Of course, the cause might be aliens, but we don't have any evidence of > that either. :-| > > What we do know is that CreateProcess is returning success, and the > child is exiting with 128 no_such_child, and that logging out can > trigger it sometimes. > > -- > Bruce Momjian <br...@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + >
