From 7c077ff2f0d922a2d13948db8d6c01eb791c83c6 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sun, 30 Jul 2023 10:43:27 +1200
Subject: [PATCH] Work around signalfd() oddity on WSL1.

It's not clear why setting SIGURG's disposition to SIG_DFL (which should
be no change) affects the behavior of WSL1 (one of the ways that Windows
can run Linux programs).  It's harmles to do that on Linux, so let's add
that workaround to help WSL1 users.  Based on research done by  Elvis
Pranskevichus in a WSL bug report:

https://github.com/microsoft/WSL/issues/8619

Discussion: https://postgr.es/m/CAEP4nAymAZP1VEBNoWAQca85ZtU5YxuwS95%2BVu%2BXW%2B-eMfq_vQ%40mail.gmail.com

diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c
index db889385b7..06dc7c503a 100644
--- a/src/backend/storage/ipc/latch.c
+++ b/src/backend/storage/ipc/latch.c
@@ -307,6 +307,12 @@ InitializeLatchSupport(void)
 	if (signal_fd < 0)
 		elog(FATAL, "signalfd() failed");
 	ReserveExternalFD();
+
+	/*
+	 * Setting this to its default disposition (ignored) appears to be
+	 * redundant, but seems to fix a problem with signalfd() on WSL1 kernels.
+	 */
+	pqsignal(SIGURG, SIG_DFL);
 #endif
 
 #ifdef WAIT_USE_KQUEUE
-- 
2.39.2