Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-cygwinpgsql-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

pgsql-cygwin by date

Next:From: Tom LaneDate: 2001-12-17 01:47:24
Subject: Re: [HACKERS] unexpected SIGALRM
Previous:From: Tom LaneDate: 2001-12-17 00:11:45
Subject: Re: [HACKERS] unexpected SIGALRM

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-12-17 01:47:24
Subject: Re: [HACKERS] unexpected SIGALRM
Previous:From: Tom LaneDate: 2001-12-17 00:11:45
Subject: Re: [HACKERS] unexpected SIGALRM

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group