On Tue, Aug 24, 2010 at 21:39, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander <mag...@hagander.net> wrote: >> On Tue, Aug 24, 2010 at 15:58, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Bruce Momjian <br...@momjian.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
