On 5 May 2011 22:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, May 5, 2011 at 4:05 PM, Tom Lane <tgl@sss.pgh.pa.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
