2013-03-17 16:07 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>> 2013-03-17 04:48 keltezéssel, 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.
I see.
> 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?
Best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/