postgres.git / summary / log / commit / refs
commit 23078689a9921968ac0873b017be6e7f772f10bc
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue May 01 00:09:31 2018 +0000
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 0f140e7a369..71b1bc3ec4c 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");
[parent: 73042b8d136f]