Re: unexpected SIGALRM - Mailing list pgsql-hackers

From Tom Lane
Subject Re: unexpected SIGALRM
Date
Msg-id 27674.1008553644@sss.pgh.pa.us
Whole thread Raw
In response to Re: unexpected SIGALRM  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> I'm not excited about inserting an ad-hoc test to work
>> around (only) one manifestation of a system-level bug.

> OK so cygwin isn't considered as a supported platform ?

I don't consider it our responsibility to work around cygwin bugs,
as opposed to reporting said bugs and expecting the cygwin folk to
fix 'em.

If the cost of such a workaround is minimal, then I'd be willing to
consider it; but in this case, you're talking about adding another pair
of kernel calls to every lock blockage.  That seems nontrivial.
But the more important argument is this: if cygwin contains a bug that
allows it to fire interrupts when it should not, how much improvement
do we really get from plugging this one hole?  Surely there are other
places that will have similar problems.  For that matter, how can you
be sure that adding a sigsetmask call will prevent it from firing the
interrupt --- how is that any more secure than setitimer?

I'd say the correct course of action is to report the problem to the
cygwin people first, and ask them whether a user-level workaround is
possible/useful.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Peter Harvey
Date:
Subject: ODBC on OSX
Next
From: Lamar Owen
Date:
Subject: Re: Explicit config patch 7.2B4