From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-cygwin(at)postgresql(dot)org |
Subject: | Re: [HACKERS] unexpected SIGALRM |
Date: | 2001-12-17 01:34:02 |
Message-ID: | 3C1D4B8A.F36ED6B6@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-cygwin pgsql-hackers |
Tom Lane wrote:
>
> "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 sure if it's a cygwin issue.
Isn't it preferable for a dbms to be insensitive to
other(e.g OS's) bugs anyway ?
Or how about blocking SIGALRM signals except when
the backend is waiting for a lock ? It seems a better
fix because it would also fix another issue.
> 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 ?
retgards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-17 01:47:24 | Re: [HACKERS] unexpected SIGALRM |
Previous Message | Tom Lane | 2001-12-17 00:11:45 | Re: [HACKERS] unexpected SIGALRM |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-17 01:47:24 | Re: [HACKERS] unexpected SIGALRM |
Previous Message | Tom Lane | 2001-12-17 00:11:45 | Re: [HACKERS] unexpected SIGALRM |