From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Kris Kennaway <kris(at)obsecurity(dot)org>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: postgresql and process titles |
Date: | 2006-06-14 08:34:19 |
Message-ID: | 20060614083419.GB4748@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 13, 2006 at 10:36:27PM -0400, Tom Lane wrote:
> * not clear whether the interrupt happens when waiting for I/O. I
> already mentioned that this would be a problem for EXPLAIN ANALYZE,
> but it might be no big deal for the other uses.
If we're going y UNIX signal semantics, in theory any interruptable
function (as listed on the signal manpage) would be interrupted every N
milliseconds to handle the interrupt. So yes, if possible the interrupt
will be serviced anyway, even during I/O, by aborting a restarting the
I/O continuously. Not terribly efficient.
With one big exception: sometimes I/O is non-interruptable (the good
old D state). In this case the interrupts will happen but will simply
be queued and in fact will all be dropped except the last one
(non-realtime signals are never stacked). The handler will probably be
called the moment it returns to user-space.
Note: Do we want SIGPROF, SIGALRM or SIGVTALRM? There's apparently a
distinction, see: http://en.wikipedia.org/wiki/SIGPROF
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-14 11:22:52 | Re: CSV mode option for pg_dump |
Previous Message | Martijn van Oosterhout | 2006-06-14 08:23:45 | Re: Fabian Pascal and RDBMS deficiencies in fully implementing |