Re: Process wakeups when idle and power consumption

On 5 May 2011 22:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Why do you think that my comment is badly phrased?

> 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.

Unless all signal handlers for signals that we expect call SetLatch()
anyway, as in this case.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services