pgkill() is not POSIX-like for exiting processes

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

Browse pgsql-hackers by date

  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