Reduce chatter from signaling of autovacuum workers.

tglsfdc · tglsfdc · commit 116be6c17102 · 2015-07-28T17:34:00.000-04:00
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker.  It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case the failure is harmless.  About the only
plausible reason for reporting such cases would be to help debug corrupted
lock table contents, but this is hardly likely to be the most important
symptom if that happens.  Moreover issuing a WARNING might scare users
more than is warranted.

Also, since sending a signal to an autovacuum worker is now entirely a
routine thing, and the worker will log the query cancel on its end anyway,
reduce the message saying we're doing that from LOG to DEBUG1 level.

Very minor cosmetic cleanup as well.

Since the main practical reason for doing this is to avoid unnecessary
buildfarm failures, back-patch to all active branches.
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
@@ -1170,22 +1170,32 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
 				/* release lock as quickly as possible */
 				LWLockRelease(ProcArrayLock);
 
-				ereport(LOG,
+				/* send the autovacuum worker Back to Old Kent Road */
+				ereport(DEBUG1,
 					  (errmsg("sending cancel to blocking autovacuum PID %d",
 							  pid),
 					   errdetail_log("%s", logbuf.data)));
 
-				pfree(logbuf.data);
-				pfree(locktagbuf.data);
-
-				/* send the autovacuum worker Back to Old Kent Road */
 				if (kill(pid, SIGINT) < 0)
 				{
-					/* Just a warning to allow multiple callers */
-					ereport(WARNING,
-							(errmsg("could not send signal to process %d: %m",
-									pid)));
+					/*
+					 * There's a race condition here: once we release the
+					 * ProcArrayLock, it's possible for the autovac worker to
+					 * close up shop and exit before we can do the kill().
+					 * Therefore, we do not whinge about no-such-process.
+					 * Other errors such as EPERM could conceivably happen if
+					 * the kernel recycles the PID fast enough, but such cases
+					 * seem improbable enough that it's probably best to issue
+					 * a warning if we see some other errno.
+					 */
+					if (errno != ESRCH)
+						ereport(WARNING,
+						   (errmsg("could not send signal to process %d: %m",
+								   pid)));
 				}
+
+				pfree(logbuf.data);
+				pfree(locktagbuf.data);
 			}
 			else
 				LWLockRelease(ProcArrayLock);
