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. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
