mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Does it help to wait before reattaching?

Browse Source 
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
This commit is contained in:
Tom Lane 2018-04-30 20:09:31 -04:00
parent 73042b8d13
commit 23078689a9
1 changed files with 4 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
src/backend/port/win32_shmem.c
View File

@ -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");