Re: Strange Windows problem, lock_timeout test request
От | Tom Lane |
---|---|
Тема | Re: Strange Windows problem, lock_timeout test request |
Дата | |
Msg-id | 21445.1363575131@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Strange Windows problem, lock_timeout test request (Boszormenyi Zoltan <zb@cybertec.at>) |
Ответы |
Re: Strange Windows problem, lock_timeout test request
|
Список | 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 по дате отправления: