From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | pgkill() is not POSIX-like for exiting processes |
Date: | 2014-07-23 01:24:12 |
Message-ID: | 20140723012412.GA2403774@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
My new OpenLDAP test case has been breaking each MSVC buildfarm member. Most
MinGW members are fine, though the 9.0 and 9.1 narwhal members broke. (Newer
narwhal members have been broken long-term.) The MSVC build system has a
mundane inability to handle a Makefile construct I used; the first attached
patch fixes that. With that fixed, though, the test case reveals a departure
from POSIX in pgkill(), our emulation of kill(2) for Windows. A pgkill() call
falling very close in time to process exit can easily give ERROR_BROKEN_PIPE,
and I at least once observed it give ERROR_BAD_PIPE. pgkill() translates
those codes to EINVAL. Only a buggy POSIX program will ever see EINVAL from
kill(2). This situation is just like signalling a zombie, and POSIX kill(2)
returns zero for zombies. Let's do that, as attached.
I'm inclined to back-patch this, although a quick scan didn't turn up any code
having bugs today as a result. The change will affect occasional error
messages. (An alternative is to change the test case code in the back
branches to treat EINVAL like success.)
On my systems, MSVC builds get ERROR_BROKEN_PIPE far more easily than MinGW
builds. In MinGW, I ran "make -C contrib/dblink check" many times without
ever hitting the error, but "vcregress contribcheck" hit it over 99% of the
time. I don't have a theory to explain that.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
msvc-regress-top_builddir-v1.patch | text/plain | 787 bytes |
pgkill-exiting-v1.patch | text/plain | 865 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2014-07-23 01:46:14 | Re: Shared Data Structure b/w clients |
Previous Message | Tom Lane | 2014-07-23 00:39:19 | Re: Stating the significance of Lehman & Yao in the nbtree README |