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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
