postgres.git / summary / log / commit / refs

commit    9486e7b666fd113f043d5f091fd42bc1ef72acd8
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Thu Jan 07 03:02:35 2021 +0000
First released in: 14.0

    Improve commentary in timeout.c.
    
    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 | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/backend/utils/misc/timeout.c b/src/backend/utils/misc/timeout.c
index 88139ab82b6..95a273d9cfb 100644
--- a/src/backend/utils/misc/timeout.c
+++ b/src/backend/utils/misc/timeout.c
@@ -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;


[parent: 55fe26a4b580]