Does it help to wait before reattaching?

tglsfdc · tglsfdc · commit 23078689a992 · 2018-04-30T20:09:31.000-04:00
Revert the map/unmap dance I tried in commit 73042b8; that helps not at all. Instead, speculate that the unwanted allocation is being done on another thread, and thus timing variations explain the apparent unpredictability. Temporarily add a 1-second sleep before the VirtualFree call, in hopes that any such other threads will quiesce and not jog our elbow. This is obviously not a desirable long-term fix, but as a means of investigation it seems useful. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
diff --git a/src/backend/port/win32_shmem.c b/src/backend/port/win32_shmem.c
@@ -456,22 +456,11 @@ PGSharedMemoryReAttach(void)
 	/* Ensure buf is big enough that it won't grow mid-operation */
 	initStringInfo(&buf);
 	enlargeStringInfo(&buf, 128 * 1024);
+	/* ... and let's just be sure all that space is committed */
+	memset(buf.data, 0, buf.maxlen);
 
-	dumpmem(&buf, "beginning PGSharedMemoryReAttach");
-
-	hdr = (PGShmemHeader *) MapViewOfFileEx(UsedShmemSegID, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0, NULL);
-	if (hdr)
-	{
-		if (!UnmapViewOfFile(hdr))
-			elog(LOG, "could not unmap temporary view of shared memory: error code %lu",
-				 GetLastError());
-	}
-	else
-	{
-		/* This isn't fatal, just unpromising ... */
-		elog(LOG, "could not attach to shared memory (key=%p) at any address: error code %lu",
-			 UsedShmemSegID, GetLastError());
-	}
+	/* Test: see if this lets the process address space quiesce */
+	pg_usleep(1000000L);
 
 	dumpmem(&buf, "before VirtualFree");
 
