| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 02:02:53 |
| Message-ID: | 20130616020252.GV6417@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> 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.
Is there really serious overhead from using latches..? I thought much
of the point of that approach was specifically to minimize overhead...
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-06-16 02:32:47 | Re: stray SIGALRM |
| Previous Message | Alvaro Herrera | 2013-06-16 01:54:16 | Re: stray SIGALRM |