Re: unexpected SIGALRM

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: unexpected SIGALRM
Дата
Msg-id 27674.1008553644@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: unexpected SIGALRM  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Peter Harvey
Дата:
Сообщение: ODBC on OSX
Следующее
От: Lamar Owen
Дата:
Сообщение: Re: Explicit config patch 7.2B4