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

On Tue, Aug 24, 2010 at 21:39, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>>> Robert Haas wrote:
>>>>> Yeah, that seems very plausible, although exactly how to verify I don't know.
>>>
>>>> And here is confirmation from the Microsoft web site:
>>>
>>>>       In some instances, calling GetExitCode() against the failed process
>>>>       indicates the following exit code:
>>>>       128L ERROR_WAIT_NO_CHILDREN - There are no child processes to wait for.
>>>
>>> Given the existence of the deadman switch mechanism (which I hadn't
>>> remembered when this thread started), I'm coming around to the idea that
>>> we could just treat exit(128) as nonfatal on Windows.  If for some
>>> reason the child hadn't died instantly at startup, the deadman switch
>>> would distinguish that from the case described here.
>>
>> Just because I had written it before you posted that, here's how the
>> win32-specific-set-a-flag-when-we're-in-control thing would look. But
>> if we're convinced that just ignoring error 128 is safe, then that's
>> obviously a simpler patch..
>
> So, if we do this, what will happen to the client connection that was
> due to be handled by the backend being spawned?  Is this going to lead
> to extra fds accumulating or any such thing?

I don't see why. The process goes away, and with it goes all the
handles. And the postmaster still closes all sockets and handles the
same way it did before.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/