Improve commentary in timeout.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 7 Jan 2021 03:02:35 +0000 (22:02 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 7 Jan 2021 03:09:16 +0000 (22:09 -0500)
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

src/backend/utils/misc/timeout.c

index 88139ab82b6888752a7adfe134bd6579eafce1d7..95a273d9cfbdbd672e3d3d6eba594df4fec164c5 100644 (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;