Re: [HACKERS] unexpected SIGALRM

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

In response to

Responses

Browse pgsql-cygwin by date

  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

Browse pgsql-hackers by date

  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