Re: Strange Windows problem, lock_timeout test request

Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> 2013-03-17 04:48 keltezssel, Tom Lane rta:
>> [ worries about stray SIGALRM events ]

> Your reasoning seems to be correct. However, if we take it to the
> extreme, enable_timeout_at/enable_timeout_after/enable_timeouts
> should also disable the interrupt handler at the beginning of the
> function and enabled at the end with pqsignal(). An evil soul may
> send SIGALRM externally to the backend processes at the proper
> moment and create a race condition while enable_timeout*() is in
> progress and the itimer is about to trigger at the same time (but
> doesn't since it was disabled).

Well, a malefactor with the ability to send signals to a backend
process could also send SIGKILL, or any number of other signals that
would mess things up. I'm not too concerned about that scenario.
I *am* concerned about leftover timer events, both because this code
isn't very well tested, and because third-party code loaded into the
backend (think pl/perl for instance) could easily set up timer events
we weren't expecting.

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.

regards, tom lane