Stephen Frost writes:
> Is there really serious overhead from using latches..?
IIRC there's at least one gettimeofday() involved in WaitLatch. There
are platforms on which that already costs more than you want to spend
for, say, CommitDelay.
regards, tom lane
--
Sent
* Alvaro Herrera (alvhe...@2ndquadrant.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
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 wou
I wrote:
> ... Also, our switch to latches for sleeping purposes
> should have ameliorated the issue of signals failing to wake processes
> when we wanted them to.
> Let's turn on SA_RESTART for SIGALRM in HEAD and 9.3 and see what beta
> testing says.
I experimented with this a bit on my old HPU
Andres Freund writes:
> On 2013-06-15 11:29:45 -0400, Tom Lane wrote:
>> Hmm. Personally I'd rather go in the other direction:
>> http://www.postgresql.org/message-id/12819.1183306...@sss.pgh.pa.us
> I am not actually objecting that reasoning, I think it would be rather
> useful to get there.
>
On 2013-06-15 11:29:45 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
> >> On reflection though, we *do* need to make them cope, because even
> >> without lazy SIGALRM disable, any such place is still at risk. We
> >> surely must allow for the pos
Andres Freund writes:
> On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
>> On reflection though, we *do* need to make them cope, because even
>> without lazy SIGALRM disable, any such place is still at risk. We
>> surely must allow for the possibility of SIGHUP arriving at any instant,
>> for examp
On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
> I wrote:
> > Richard Poole writes:
> >> This behaviour appears in 6ac7facdd3990baf47efc124e9d7229422a06452 as a
> >> side-effect of speeding things up by getting rid of setitimer() calls;
> >> it's not obvious what's a good way to fix it without losi
I wrote:
> Richard Poole writes:
>> This behaviour appears in 6ac7facdd3990baf47efc124e9d7229422a06452 as a
>> side-effect of speeding things up by getting rid of setitimer() calls;
>> it's not obvious what's a good way to fix it without losing the benefits
>> of that commit.
> Ugh. It doesn't s
Richard Poole writes:
> In 9.3beta1, a backend will receive a SIGALRM after authentication_timeout
> seconds, even if authentication has been successful. Most of the time
> this doesn't hurt anyone, but there are cases, such as when the backend
> is doing the open() of a backend copy, when it brea
In 9.3beta1, a backend will receive a SIGALRM after authentication_timeout
seconds, even if authentication has been successful. Most of the time
this doesn't hurt anyone, but there are cases, such as when the backend
is doing the open() of a backend copy, when it breaks things and results
in an err
11 matches
Mail list logo
