From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>, "'Craig Ringer'" <craig(at)2ndQuadrant(dot)com>, 'Hans-Jürgen Schönig' <hs(at)cybertec(dot)at>, "'Ants Aasma'" <ants(at)cybertec(dot)at>, "'PostgreSQL Hackers'" <pgsql-hackers(at)postgresql(dot)org>, "'Amit kapila'" <amit(dot)kapila(at)huawei(dot)com> |
Subject: | Re: Strange Windows problem, lock_timeout test request |
Date: | 2013-03-18 02:52:11 |
Message-ID: | 21445.1363575131@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> 2013-03-17 16:07 keltezssel, 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-03-18 02:57:51 | Re: [v9.3] OAT_POST_ALTER object access hooks |
Previous Message | Craig Ringer | 2013-03-18 01:54:34 | Re: [HACKERS] Trust intermediate CA for client certificates |