Fix double-release of spinlock

Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal
flags, but in EmitProcSignalBarrier(), the spinlock was released
twice. With most spinlock implementations, releasing a lock that's not
held is not easy to notice, because most of the time it does nothing,
but if the spinlock was concurrently acquired by another process, it
could lead to more serious issues. Fortunately, with the
--disable-spinlocks emulation implementation, it caused more visible
failures.

In the passing, fix a type in comment and add an assertion that the
procNumber passed to SendProcSignal looks valid.

Discussion: https://www.postgresql.org/message-id/[email protected]

1 files changed, 4 insertions, 2 deletions

diff --git a/src/backend/storage/ipc/procsignal.c b/src/backend/storage/ipc/procsignal.c
index 038aeca6151..87027f27eb7 100644
--- a/src/backend/storage/ipc/procsignal.c
+++ b/src/backend/storage/ipc/procsignal.c
@@ -284,6 +284,7 @@ SendProcSignal(pid_t pid, ProcSignalReason reason, ProcNumber procNumber)
 
 	if (procNumber != INVALID_PROC_NUMBER)
 	{
+		Assert(procNumber < NumProcSignalSlots);
 		slot = &ProcSignal->psh_slot[procNumber];
 
 		SpinLockAcquire(&slot->pss_mutex);
@@ -300,7 +301,7 @@ SendProcSignal(pid_t pid, ProcSignalReason reason, ProcNumber procNumber)
 	else
 	{
 		/*
-		 * Pronumber not provided, so search the array using pid.  We search
+		 * procNumber not provided, so search the array using pid.  We search
 		 * the array back to front so as to reduce search overhead.  Passing
 		 * INVALID_PROC_NUMBER means that the target is most likely an
 		 * auxiliary process, which will have a slot near the end of the
@@ -404,7 +405,8 @@ EmitProcSignalBarrier(ProcSignalBarrierType type)
 				SpinLockRelease(&slot->pss_mutex);
 				kill(pid, SIGUSR1);
 			}
-			SpinLockRelease(&slot->pss_mutex);
+			else
+				SpinLockRelease(&slot->pss_mutex);
 		}
 	}