From 23078689a9921968ac0873b017be6e7f772f10bc Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 30 Apr 2018 20:09:31 -0400 Subject: [PATCH] Does it help to wait before reattaching? Revert the map/unmap dance I tried in commit 73042b8d1; 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 --- src/backend/port/win32_shmem.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/src/backend/port/win32_shmem.c b/src/backend/port/win32_shmem.c index 0f140e7a36..71b1bc3ec4 100644 --- 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"); -- 2.40.0