| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Richard Poole <richard(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: stray SIGALRM |
| Date: | 2013-06-16 01:54:16 |
| Message-ID: | 20130616015416.GG3753@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> In general, we might want to consider replacing long sleep intervals
> with WaitLatch operations. I thought for a bit about trying to turn
> pg_usleep itself into a WaitLatch call; but it's also used in frontend
> code where that wouldn't work, and anyway it's not clear this would be
> a good thing for short sleeps.
How about having a #ifdef !FRONTEND code path that uses the latch, and
sleep otherwise? And maybe use plain sleep for short sleeps in the
backend also, to avoid the latch overhead. I notice we already have
three implementations of pg_usleep.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2013-06-16 02:02:53 | Re: stray SIGALRM |
| Previous Message | Robert Haas | 2013-06-16 01:53:59 | Re: pluggable compression support |