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

Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session

From: Cristian Bittel <cbittel(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chris Travers <chris(at)metatrontech(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session
Date: 2010-09-01 14:49:52
Message-ID: AANLkTinuwmzyf2UwF0RFkVyFdVaX-HaunJmRk6=Z2axg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
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 <bruce(at)momjian(dot)us>

> Dave Page wrote:
> > On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > Dave Page wrote:
> > >> On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian <bruce(at)momjian(dot)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  <bruce(at)momjian(dot)us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + It's impossible for everything to be true. +
>

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-09-01 15:00:12
Subject: Re: Path question
Previous:From: Michael MeskesDate: 2010-09-01 14:41:07
Subject: Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

pgsql-bugs by date

Next:From: Dave PageDate: 2010-09-01 15:13:42
Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session
Previous:From: Fabien COELHODate: 2010-09-01 14:22:49
Subject: Re: issue about information_schema REFERENTIAL_CONSTRAINTS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group