| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, pgsql-cygwin(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] unexpected SIGALRM |
| Date: | 2001-12-17 00:11:45 |
| Message-ID: | 27163.1008547905@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-cygwin pgsql-hackers |
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> Anyway I found some unexpected SIGALRM cases.
> It may be caused by a cygwin's bug but isn't it safer to
> return immediately from HandleDeadLock in any platform
> unless the backend is waiting for a lock ?
If we can't rely on the signal handling facilities to interrupt only
when they're supposed to, I think HandleDeadlock is the least of our
worries :-(. I'm not excited about inserting an ad-hoc test to work
around (only) one manifestation of a system-level bug.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2001-12-17 01:34:02 | Re: [HACKERS] unexpected SIGALRM |
| Previous Message | Hiroshi Inoue | 2001-12-16 21:56:53 | unexpected SIGALRM |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2001-12-17 01:34:02 | Re: [HACKERS] unexpected SIGALRM |
| Previous Message | mlw | 2001-12-16 22:37:13 | Re: Explicit config patch 7.2B4 |