diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index 324347b2c5879349f92cbbeaf126467eeb64c403..884e91b7364a32fd0227708bd0ad672b17150a11 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -1167,22 +1167,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);