mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Improve commentary in timeout.c.

Browse Source 
On re-reading I realized that I'd missed one race condition in the new
timeout code.  It's safe, but add a comment explaining it.

Discussion: https://postgr.es/m/CA+hUKG+o6pbuHBJSGnud=TadsuXySWA7CCcPgCt2QE9F6_4iHQ@mail.gmail.com
This commit is contained in:
Tom Lane 2021-01-06 22:02:35 -05:00
parent 55fe26a4b5
commit 9486e7b666
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/utils/misc/timeout.c
View File

@ -307,7 +307,14 @@ schedule_alarm(TimestampTz now)
* signal is still coming.
*
* Other race conditions involved with setting/checking signal_pending
* are okay, for the reasons described above.
* are okay, for the reasons described above. One additional point is
* that the signal handler could fire after we set signal_due_at, but
* still before the setitimer() call. Then the handler could
* overwrite signal_due_at with a value it computes, which will be the
* same as or perhaps later than what we just computed. After we
* perform setitimer(), the net effect would be that signal_due_at
* gives a time later than when the interrupt will really happen;
* which is a safe situation.
*/
signal_due_at = nearest_timeout;
signal_pending = true;