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 по дате отправления: