Re: Strange Windows problem, lock_timeout test request - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Strange Windows problem, lock_timeout test request
Date
Msg-id 21445.1363575131@sss.pgh.pa.us
Whole thread Raw
In response to Re: Strange Windows problem, lock_timeout test request  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: Strange Windows problem, lock_timeout test request  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> writes:
> 2013-03-17 16:07 keltez�ssel, Tom Lane �rta:
>> It suddenly occurs to me though that there's more than one way to skin
>> this cat.  We could easily add another static flag variable called
>> "sigalrm_allowed" or some such, and have the signal handler test that
>> and immediately return without doing anything if it's off.  Clearing
>> and setting such a variable would be a lot cheaper than an extra
>> setitimer call, as well as more robust since it would protect us from
>> all sources of SIGALRM not just ITIMER_REAL.

> Something like the attached patch?

Well, something like that, but it still needed some improvements.  In
particular I thought it best to leave the signal handler still releasing
the procLatch unconditionally --- that behavior is independent of what
this module is doing.  Also you seem to have some odd ideas about what
do-while will accomplish.  AFAIK, in this usage it's purely a syntactic
trick without much semantic content.  It's the marking of the variable
as "volatile" that counts for telling the compiler not to re-order
operations.

Updated and committed.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Trust intermediate CA for client certificates
Next
From: Robert Haas
Date:
Subject: Re: [v9.3] OAT_POST_ALTER object access hooks