Re: Process wakeups when idle and power consumption

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, May 5, 2011 at 4:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> + * The caveat about signals invalidating the timeout of
>>> + * WaitLatch() on some platforms can be safely disregarded,

>> Really?

> I'm a bit confused by the phrasing of this comment as well, but it
> does seem to me that if all the relevant signal handlers set the
> latch, then it ought not to be necessary to break the sleep down into
> one-second intervals.

[ reads code some more ... ] Yeah, I think you are probably right,
which makes it just a badly phrased comment. The important point here
is that the self-pipe trick in unix_latch.c fixes the problem, so long
as we are relying on latch release and NOT timeout-driven wakeup.

What that really means is that any WaitOnLatch call with a finite
timeout ought to be viewed with a jaundiced eye. Ideally, we want them
all to be waiting for latch release and nothing else. I'm concerned
that we're going to be moving towards some intermediate state where we
have WaitOnLatch calls with very long timeouts, because the longer the
timeout, the worse the problem gets on platforms that have the problem.
If you have say a 1-minute timeout, it's not difficult to believe that
you'll basically never wake up because of random signals resetting the
timeout.

regards, tom lane