On 5 May 2011 22:22, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, May 5, 2011 at 4:05 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
