2007-03-21 15:39:23 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* win32_shmem.c
|
|
|
|
* Implement shared memory using win32 facilities
|
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2007-03-21 15:39:23 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/port/win32_shmem.c
|
2007-03-21 15:39:23 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "miscadmin.h"
|
2014-04-09 17:38:52 +02:00
|
|
|
#include "storage/dsm.h"
|
2007-03-21 15:39:23 +01:00
|
|
|
#include "storage/ipc.h"
|
|
|
|
#include "storage/pg_shmem.h"
|
|
|
|
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
HANDLE UsedShmemSegID = INVALID_HANDLE_VALUE;
|
2007-03-21 15:39:23 +01:00
|
|
|
void *UsedShmemSegAddr = NULL;
|
2009-07-24 22:12:42 +02:00
|
|
|
static Size UsedShmemSegSize = 0;
|
2007-03-21 15:39:23 +01:00
|
|
|
|
2018-01-21 15:40:46 +01:00
|
|
|
static bool EnableLockPagesPrivilege(int elevel);
|
2007-03-21 15:39:23 +01:00
|
|
|
static void pgwin32_SharedMemoryDelete(int status, Datum shmId);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Generate shared memory segment name. Expand the data directory, to generate
|
|
|
|
* an identifier unique for this data directory. Then replace all backslashes
|
|
|
|
* with forward slashes, since backslashes aren't permitted in global object names.
|
|
|
|
*
|
|
|
|
* Store the shared memory segment in the Global\ namespace (requires NT2 TSE or
|
|
|
|
* 2000, but that's all we support for other reasons as well), to make sure you can't
|
|
|
|
* open two postmasters in different sessions against the same data directory.
|
|
|
|
*
|
|
|
|
* XXX: What happens with junctions? It's only someone breaking things on purpose,
|
|
|
|
* and this is still better than before, but we might want to do something about
|
|
|
|
* that sometime in the future.
|
|
|
|
*/
|
|
|
|
static char *
|
|
|
|
GetSharedMemName(void)
|
|
|
|
{
|
|
|
|
char *retptr;
|
|
|
|
DWORD bufsize;
|
|
|
|
DWORD r;
|
|
|
|
char *cp;
|
|
|
|
|
|
|
|
bufsize = GetFullPathName(DataDir, 0, NULL, NULL);
|
|
|
|
if (bufsize == 0)
|
2011-08-23 21:00:52 +02:00
|
|
|
elog(FATAL, "could not get size for full pathname of datadir %s: error code %lu",
|
2007-03-21 15:39:23 +01:00
|
|
|
DataDir, GetLastError());
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
retptr = malloc(bufsize + 18); /* 18 for Global\PostgreSQL: */
|
2007-03-21 15:39:23 +01:00
|
|
|
if (retptr == NULL)
|
|
|
|
elog(FATAL, "could not allocate memory for shared memory name");
|
|
|
|
|
|
|
|
strcpy(retptr, "Global\\PostgreSQL:");
|
2008-07-04 12:50:18 +02:00
|
|
|
r = GetFullPathName(DataDir, bufsize, retptr + 18, NULL);
|
2007-03-21 15:39:23 +01:00
|
|
|
if (r == 0 || r > bufsize)
|
2011-08-23 21:00:52 +02:00
|
|
|
elog(FATAL, "could not generate full pathname for datadir %s: error code %lu",
|
2007-03-21 15:39:23 +01:00
|
|
|
DataDir, GetLastError());
|
|
|
|
|
2009-06-11 16:49:15 +02:00
|
|
|
/*
|
2008-10-30 18:04:09 +01:00
|
|
|
* XXX: Intentionally overwriting the Global\ part here. This was not the
|
|
|
|
* original approach, but putting it in the actual Global\ namespace
|
2009-06-11 16:49:15 +02:00
|
|
|
* causes permission errors in a lot of cases, so we leave it in the
|
|
|
|
* default namespace for now.
|
2008-10-30 18:04:09 +01:00
|
|
|
*/
|
|
|
|
for (cp = retptr; *cp; cp++)
|
2007-03-21 15:39:23 +01:00
|
|
|
if (*cp == '\\')
|
|
|
|
*cp = '/';
|
|
|
|
|
|
|
|
return retptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PGSharedMemoryIsInUse
|
|
|
|
*
|
|
|
|
* Is a previously-existing shmem segment still existing and in use?
|
|
|
|
*
|
|
|
|
* The point of this exercise is to detect the case where a prior postmaster
|
2014-05-06 18:12:18 +02:00
|
|
|
* crashed, but it left child backends that are still running. Therefore
|
2007-03-21 15:39:23 +01:00
|
|
|
* we only care about shmem segments that are associated with the intended
|
|
|
|
* DataDir. This is an important consideration since accidental matches of
|
|
|
|
* shmem segment IDs are reasonably common.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
PGSharedMemoryIsInUse(unsigned long id1, unsigned long id2)
|
|
|
|
{
|
|
|
|
char *szShareMem;
|
|
|
|
HANDLE hmap;
|
|
|
|
|
|
|
|
szShareMem = GetSharedMemName();
|
|
|
|
|
|
|
|
hmap = OpenFileMapping(FILE_MAP_READ, FALSE, szShareMem);
|
|
|
|
|
|
|
|
free(szShareMem);
|
|
|
|
|
|
|
|
if (hmap == NULL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
CloseHandle(hmap);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-01-21 15:40:46 +01:00
|
|
|
/*
|
|
|
|
* EnableLockPagesPrivilege
|
|
|
|
*
|
|
|
|
* Try to acquire SeLockMemoryPrivilege so we can use large pages.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
EnableLockPagesPrivilege(int elevel)
|
|
|
|
{
|
2018-04-26 20:47:16 +02:00
|
|
|
HANDLE hToken;
|
2018-01-21 15:40:46 +01:00
|
|
|
TOKEN_PRIVILEGES tp;
|
2018-04-26 20:47:16 +02:00
|
|
|
LUID luid;
|
2018-01-21 15:40:46 +01:00
|
|
|
|
|
|
|
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
|
|
|
|
{
|
|
|
|
ereport(elevel,
|
|
|
|
(errmsg("could not enable Lock Pages in Memory user right: error code %lu", GetLastError()),
|
|
|
|
errdetail("Failed system call was %s.", "OpenProcessToken")));
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!LookupPrivilegeValue(NULL, SE_LOCK_MEMORY_NAME, &luid))
|
|
|
|
{
|
|
|
|
ereport(elevel,
|
|
|
|
(errmsg("could not enable Lock Pages in Memory user right: error code %lu", GetLastError()),
|
|
|
|
errdetail("Failed system call was %s.", "LookupPrivilegeValue")));
|
|
|
|
CloseHandle(hToken);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
tp.PrivilegeCount = 1;
|
|
|
|
tp.Privileges[0].Luid = luid;
|
|
|
|
tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
|
|
|
|
|
|
|
|
if (!AdjustTokenPrivileges(hToken, FALSE, &tp, 0, NULL, NULL))
|
|
|
|
{
|
|
|
|
ereport(elevel,
|
|
|
|
(errmsg("could not enable Lock Pages in Memory user right: error code %lu", GetLastError()),
|
|
|
|
errdetail("Failed system call was %s.", "AdjustTokenPrivileges")));
|
|
|
|
CloseHandle(hToken);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (GetLastError() != ERROR_SUCCESS)
|
|
|
|
{
|
|
|
|
if (GetLastError() == ERROR_NOT_ALL_ASSIGNED)
|
|
|
|
ereport(elevel,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("could not enable Lock Pages in Memory user right"),
|
|
|
|
errhint("Assign Lock Pages in Memory user right to the Windows user account which runs PostgreSQL.")));
|
|
|
|
else
|
|
|
|
ereport(elevel,
|
|
|
|
(errmsg("could not enable Lock Pages in Memory user right: error code %lu", GetLastError()),
|
|
|
|
errdetail("Failed system call was %s.", "AdjustTokenPrivileges")));
|
|
|
|
CloseHandle(hToken);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
CloseHandle(hToken);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* PGSharedMemoryCreate
|
|
|
|
*
|
|
|
|
* Create a shared memory segment of the given size and initialize its
|
|
|
|
* standard header.
|
|
|
|
*
|
|
|
|
* makePrivate means to always create a new segment, rather than attach to
|
|
|
|
* or recycle any existing segment. On win32, we always create a new segment,
|
|
|
|
* since there is no need for recycling (segments go away automatically
|
|
|
|
* when the last backend exits)
|
|
|
|
*/
|
|
|
|
PGShmemHeader *
|
2014-04-08 17:39:55 +02:00
|
|
|
PGSharedMemoryCreate(Size size, bool makePrivate, int port,
|
|
|
|
PGShmemHeader **shim)
|
2007-03-21 15:39:23 +01:00
|
|
|
{
|
|
|
|
void *memAddress;
|
|
|
|
PGShmemHeader *hdr;
|
|
|
|
HANDLE hmap,
|
|
|
|
hmap2;
|
|
|
|
char *szShareMem;
|
2009-05-05 11:48:51 +02:00
|
|
|
int i;
|
2010-01-02 13:18:45 +01:00
|
|
|
DWORD size_high;
|
|
|
|
DWORD size_low;
|
2018-01-21 15:40:46 +01:00
|
|
|
SIZE_T largePageSize = 0;
|
|
|
|
Size orig_size = size;
|
|
|
|
DWORD flProtect = PAGE_READWRITE;
|
Allow using huge TLB pages on Linux (MAP_HUGETLB)
This patch adds an option, huge_tlb_pages, which allows requesting the
shared memory segment to be allocated using huge pages, by using the
MAP_HUGETLB flag in mmap(). This can improve performance.
The default is 'try', which means that we will attempt using huge pages,
and fall back to non-huge pages if it doesn't work. Currently, only Linux
has MAP_HUGETLB. On other platforms, the default 'try' behaves the same as
'off'.
In the passing, don't try to round the mmap() size to a multiple of
pagesize. mmap() doesn't require that, and there's no particular reason for
PostgreSQL to do that either. When using MAP_HUGETLB, however, round the
request size up to nearest 2MB boundary. This is to work around a bug in
some Linux kernel versions, but also to avoid wasting memory, because the
kernel will round the size up anyway.
Many people were involved in writing this patch, including Christian Kruse,
Richard Poole, Abhijit Menon-Sen, reviewed by Peter Geoghegan, Andres Freund
and me.
2014-01-29 12:44:45 +01:00
|
|
|
|
2007-03-21 15:39:23 +01:00
|
|
|
/* Room for a header? */
|
|
|
|
Assert(size > MAXALIGN(sizeof(PGShmemHeader)));
|
|
|
|
|
|
|
|
szShareMem = GetSharedMemName();
|
|
|
|
|
|
|
|
UsedShmemSegAddr = NULL;
|
|
|
|
|
2018-01-21 15:40:46 +01:00
|
|
|
if (huge_pages == HUGE_PAGES_ON || huge_pages == HUGE_PAGES_TRY)
|
|
|
|
{
|
|
|
|
/* Does the processor support large pages? */
|
|
|
|
largePageSize = GetLargePageMinimum();
|
|
|
|
if (largePageSize == 0)
|
|
|
|
{
|
|
|
|
ereport(huge_pages == HUGE_PAGES_ON ? FATAL : DEBUG1,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("the processor does not support large pages")));
|
|
|
|
ereport(DEBUG1,
|
|
|
|
(errmsg("disabling huge pages")));
|
|
|
|
}
|
|
|
|
else if (!EnableLockPagesPrivilege(huge_pages == HUGE_PAGES_ON ? FATAL : DEBUG1))
|
|
|
|
{
|
|
|
|
ereport(DEBUG1,
|
|
|
|
(errmsg("disabling huge pages")));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Huge pages available and privilege enabled, so turn on */
|
|
|
|
flProtect = PAGE_READWRITE | SEC_COMMIT | SEC_LARGE_PAGES;
|
|
|
|
|
|
|
|
/* Round size up as appropriate. */
|
|
|
|
if (size % largePageSize != 0)
|
|
|
|
size += largePageSize - (size % largePageSize);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
retry:
|
2010-01-02 13:18:45 +01:00
|
|
|
#ifdef _WIN64
|
|
|
|
size_high = size >> 32;
|
|
|
|
#else
|
|
|
|
size_high = 0;
|
|
|
|
#endif
|
|
|
|
size_low = (DWORD) size;
|
|
|
|
|
2007-03-21 15:39:23 +01:00
|
|
|
/*
|
2009-05-05 11:48:51 +02:00
|
|
|
* When recycling a shared memory segment, it may take a short while
|
|
|
|
* before it gets dropped from the global namespace. So re-try after
|
2009-06-11 16:49:15 +02:00
|
|
|
* sleeping for a second, and continue retrying 10 times. (both the 1
|
|
|
|
* second time and the 10 retries are completely arbitrary)
|
2007-03-21 15:39:23 +01:00
|
|
|
*/
|
2009-05-05 11:48:51 +02:00
|
|
|
for (i = 0; i < 10; i++)
|
2007-03-21 15:39:23 +01:00
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
/*
|
|
|
|
* In case CreateFileMapping() doesn't set the error code to 0 on
|
|
|
|
* success
|
|
|
|
*/
|
2009-05-04 10:36:40 +02:00
|
|
|
SetLastError(0);
|
|
|
|
|
2010-01-02 13:18:45 +01:00
|
|
|
hmap = CreateFileMapping(INVALID_HANDLE_VALUE, /* Use the pagefile */
|
2009-06-11 16:49:15 +02:00
|
|
|
NULL, /* Default security attrs */
|
2018-01-21 15:40:46 +01:00
|
|
|
flProtect,
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
size_high, /* Size Upper 32 Bits */
|
|
|
|
size_low, /* Size Lower 32 bits */
|
2009-05-05 11:48:51 +02:00
|
|
|
szShareMem);
|
|
|
|
|
2007-03-21 15:39:23 +01:00
|
|
|
if (!hmap)
|
2018-01-21 15:40:46 +01:00
|
|
|
{
|
|
|
|
if (GetLastError() == ERROR_NO_SYSTEM_RESOURCES &&
|
|
|
|
huge_pages == HUGE_PAGES_TRY &&
|
|
|
|
(flProtect & SEC_LARGE_PAGES) != 0)
|
|
|
|
{
|
|
|
|
elog(DEBUG1, "CreateFileMapping(%zu) with SEC_LARGE_PAGES failed, "
|
|
|
|
"huge pages disabled",
|
|
|
|
size);
|
|
|
|
|
|
|
|
/*
|
2018-04-26 20:47:16 +02:00
|
|
|
* Use the original size, not the rounded-up value, when
|
|
|
|
* falling back to non-huge pages.
|
2018-01-21 15:40:46 +01:00
|
|
|
*/
|
|
|
|
size = orig_size;
|
|
|
|
flProtect = PAGE_READWRITE;
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ereport(FATAL,
|
|
|
|
(errmsg("could not create shared memory segment: error code %lu", GetLastError()),
|
|
|
|
errdetail("Failed system call was CreateFileMapping(size=%zu, name=%s).",
|
|
|
|
size, szShareMem)));
|
|
|
|
}
|
2007-03-21 15:39:23 +01:00
|
|
|
|
2009-05-05 11:48:51 +02:00
|
|
|
/*
|
|
|
|
* If the segment already existed, CreateFileMapping() will return a
|
2009-05-05 23:51:46 +02:00
|
|
|
* handle to the existing one and set ERROR_ALREADY_EXISTS.
|
2009-05-05 11:48:51 +02:00
|
|
|
*/
|
2007-03-21 15:39:23 +01:00
|
|
|
if (GetLastError() == ERROR_ALREADY_EXISTS)
|
2009-05-05 11:48:51 +02:00
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
CloseHandle(hmap); /* Close the handle, since we got a valid one
|
|
|
|
* to the previous segment. */
|
2009-05-05 23:51:46 +02:00
|
|
|
hmap = NULL;
|
2009-05-05 11:48:51 +02:00
|
|
|
Sleep(1000);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
break;
|
2007-03-21 15:39:23 +01:00
|
|
|
}
|
|
|
|
|
2009-05-05 11:48:51 +02:00
|
|
|
/*
|
2009-05-05 23:51:46 +02:00
|
|
|
* If the last call in the loop still returned ERROR_ALREADY_EXISTS, this
|
|
|
|
* shared memory segment exists and we assume it belongs to somebody else.
|
2009-05-05 11:48:51 +02:00
|
|
|
*/
|
2009-05-05 23:51:46 +02:00
|
|
|
if (!hmap)
|
2009-05-05 11:48:51 +02:00
|
|
|
ereport(FATAL,
|
2009-06-11 16:49:15 +02:00
|
|
|
(errmsg("pre-existing shared memory block is still in use"),
|
|
|
|
errhint("Check if there are any old server processes still running, and terminate them.")));
|
2009-05-05 11:48:51 +02:00
|
|
|
|
2007-03-21 15:39:23 +01:00
|
|
|
free(szShareMem);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make the handle inheritable
|
|
|
|
*/
|
|
|
|
if (!DuplicateHandle(GetCurrentProcess(), hmap, GetCurrentProcess(), &hmap2, 0, TRUE, DUPLICATE_SAME_ACCESS))
|
|
|
|
ereport(FATAL,
|
2011-08-23 21:00:52 +02:00
|
|
|
(errmsg("could not create shared memory segment: error code %lu", GetLastError()),
|
2007-11-08 15:47:41 +01:00
|
|
|
errdetail("Failed system call was DuplicateHandle.")));
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Close the old, non-inheritable handle. If this fails we don't really
|
|
|
|
* care.
|
|
|
|
*/
|
|
|
|
if (!CloseHandle(hmap))
|
2011-08-23 21:00:52 +02:00
|
|
|
elog(LOG, "could not close handle to shared memory: error code %lu", GetLastError());
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get a pointer to the new shared memory segment. Map the whole segment
|
|
|
|
* at once, and let the system decide on the initial address.
|
|
|
|
*/
|
|
|
|
memAddress = MapViewOfFileEx(hmap2, FILE_MAP_WRITE | FILE_MAP_READ, 0, 0, 0, NULL);
|
|
|
|
if (!memAddress)
|
|
|
|
ereport(FATAL,
|
2011-08-23 21:00:52 +02:00
|
|
|
(errmsg("could not create shared memory segment: error code %lu", GetLastError()),
|
2007-11-08 15:47:41 +01:00
|
|
|
errdetail("Failed system call was MapViewOfFileEx.")));
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* OK, we created a new segment. Mark it as created by this process. The
|
|
|
|
* order of assignments here is critical so that another Postgres process
|
|
|
|
* can't see the header as valid but belonging to an invalid PID!
|
|
|
|
*/
|
|
|
|
hdr = (PGShmemHeader *) memAddress;
|
|
|
|
hdr->creatorPID = getpid();
|
|
|
|
hdr->magic = PGShmemMagic;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize space allocation status for segment.
|
|
|
|
*/
|
|
|
|
hdr->totalsize = size;
|
|
|
|
hdr->freeoffset = MAXALIGN(sizeof(PGShmemHeader));
|
2014-04-08 17:39:55 +02:00
|
|
|
hdr->dsm_control = 0;
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
/* Save info for possible future use */
|
|
|
|
UsedShmemSegAddr = memAddress;
|
2009-07-24 22:12:42 +02:00
|
|
|
UsedShmemSegSize = size;
|
2010-01-02 13:18:45 +01:00
|
|
|
UsedShmemSegID = hmap2;
|
2007-03-21 15:39:23 +01:00
|
|
|
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
/* Register on-exit routine to delete the new segment */
|
|
|
|
on_shmem_exit(pgwin32_SharedMemoryDelete, PointerGetDatum(hmap2));
|
|
|
|
|
2014-04-08 22:22:50 +02:00
|
|
|
*shim = hdr;
|
2007-03-21 15:39:23 +01:00
|
|
|
return hdr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PGSharedMemoryReAttach
|
|
|
|
*
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
* This is called during startup of a postmaster child process to re-attach to
|
|
|
|
* an already existing shared memory segment, using the handle inherited from
|
|
|
|
* the postmaster.
|
2007-03-21 15:39:23 +01:00
|
|
|
*
|
|
|
|
* UsedShmemSegID and UsedShmemSegAddr are implicit parameters to this
|
|
|
|
* routine. The caller must have already restored them to the postmaster's
|
|
|
|
* values.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
PGSharedMemoryReAttach(void)
|
|
|
|
{
|
|
|
|
PGShmemHeader *hdr;
|
|
|
|
void *origUsedShmemSegAddr = UsedShmemSegAddr;
|
|
|
|
|
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
Assert(IsUnderPostmaster);
|
|
|
|
|
2009-07-24 22:12:42 +02:00
|
|
|
/*
|
|
|
|
* Release memory region reservation that was made by the postmaster
|
|
|
|
*/
|
|
|
|
if (VirtualFree(UsedShmemSegAddr, 0, MEM_RELEASE) == 0)
|
2011-08-23 21:00:52 +02:00
|
|
|
elog(FATAL, "failed to release reserved memory region (addr=%p): error code %lu",
|
2009-07-24 22:12:42 +02:00
|
|
|
UsedShmemSegAddr, GetLastError());
|
|
|
|
|
2010-01-02 13:18:45 +01:00
|
|
|
hdr = (PGShmemHeader *) MapViewOfFileEx(UsedShmemSegID, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0, UsedShmemSegAddr);
|
2007-03-21 15:39:23 +01:00
|
|
|
if (!hdr)
|
2011-08-23 21:00:52 +02:00
|
|
|
elog(FATAL, "could not reattach to shared memory (key=%p, addr=%p): error code %lu",
|
2018-05-01 19:06:31 +02:00
|
|
|
UsedShmemSegID, UsedShmemSegAddr, GetLastError());
|
2007-03-21 15:39:23 +01:00
|
|
|
if (hdr != origUsedShmemSegAddr)
|
|
|
|
elog(FATAL, "reattaching to shared memory returned unexpected address (got %p, expected %p)",
|
|
|
|
hdr, origUsedShmemSegAddr);
|
|
|
|
if (hdr->magic != PGShmemMagic)
|
|
|
|
elog(FATAL, "reattaching to shared memory returned non-PostgreSQL memory");
|
2014-04-08 17:39:55 +02:00
|
|
|
dsm_set_control_handle(hdr->dsm_control);
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
UsedShmemSegAddr = hdr; /* probably redundant */
|
|
|
|
}
|
|
|
|
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
/*
|
|
|
|
* PGSharedMemoryNoReAttach
|
|
|
|
*
|
|
|
|
* This is called during startup of a postmaster child process when we choose
|
|
|
|
* *not* to re-attach to the existing shared memory segment. We must clean up
|
|
|
|
* to leave things in the appropriate state.
|
|
|
|
*
|
|
|
|
* The child process startup logic might or might not call PGSharedMemoryDetach
|
|
|
|
* after this; make sure that it will be a no-op if called.
|
|
|
|
*
|
|
|
|
* UsedShmemSegID and UsedShmemSegAddr are implicit parameters to this
|
|
|
|
* routine. The caller must have already restored them to the postmaster's
|
|
|
|
* values.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
PGSharedMemoryNoReAttach(void)
|
|
|
|
{
|
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
Assert(IsUnderPostmaster);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Under Windows we will not have mapped the segment, so we don't need to
|
|
|
|
* un-map it. Just reset UsedShmemSegAddr to show we're not attached.
|
|
|
|
*/
|
|
|
|
UsedShmemSegAddr = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We *must* close the inherited shmem segment handle, else Windows will
|
|
|
|
* consider the existence of this process to mean it can't release the
|
|
|
|
* shmem segment yet. We can now use PGSharedMemoryDetach to do that.
|
|
|
|
*/
|
|
|
|
PGSharedMemoryDetach();
|
|
|
|
}
|
|
|
|
|
2007-03-21 15:39:23 +01:00
|
|
|
/*
|
|
|
|
* PGSharedMemoryDetach
|
|
|
|
*
|
|
|
|
* Detach from the shared memory segment, if still attached. This is not
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
* intended to be called explicitly by the process that originally created the
|
|
|
|
* segment (it will have an on_shmem_exit callback registered to do that).
|
|
|
|
* Rather, this is for subprocesses that have inherited an attachment and want
|
|
|
|
* to get rid of it.
|
|
|
|
*
|
|
|
|
* UsedShmemSegID and UsedShmemSegAddr are implicit parameters to this
|
|
|
|
* routine.
|
2007-03-21 15:39:23 +01:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
PGSharedMemoryDetach(void)
|
|
|
|
{
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
/* Unmap the view, if it's mapped */
|
2007-03-21 15:39:23 +01:00
|
|
|
if (UsedShmemSegAddr != NULL)
|
|
|
|
{
|
|
|
|
if (!UnmapViewOfFile(UsedShmemSegAddr))
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
elog(LOG, "could not unmap view of shared memory: error code %lu",
|
|
|
|
GetLastError());
|
2007-03-21 15:39:23 +01:00
|
|
|
|
|
|
|
UsedShmemSegAddr = NULL;
|
|
|
|
}
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
|
|
|
|
/* And close the shmem handle, if we have one */
|
|
|
|
if (UsedShmemSegID != INVALID_HANDLE_VALUE)
|
|
|
|
{
|
|
|
|
if (!CloseHandle(UsedShmemSegID))
|
|
|
|
elog(LOG, "could not close handle to shared memory: error code %lu",
|
|
|
|
GetLastError());
|
|
|
|
|
|
|
|
UsedShmemSegID = INVALID_HANDLE_VALUE;
|
|
|
|
}
|
2007-03-21 15:39:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
* pgwin32_SharedMemoryDelete
|
|
|
|
*
|
|
|
|
* Detach from and delete the shared memory segment
|
|
|
|
* (called as an on_shmem_exit callback, hence funny argument list)
|
2007-03-21 15:39:23 +01:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
pgwin32_SharedMemoryDelete(int status, Datum shmId)
|
|
|
|
{
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
Assert(DatumGetPointer(shmId) == UsedShmemSegID);
|
2007-03-21 15:39:23 +01:00
|
|
|
PGSharedMemoryDetach();
|
|
|
|
}
|
2009-07-24 22:12:42 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pgwin32_ReserveSharedMemoryRegion(hChild)
|
|
|
|
*
|
|
|
|
* Reserve the memory region that will be used for shared memory in a child
|
|
|
|
* process. It is called before the child process starts, to make sure the
|
|
|
|
* memory is available.
|
|
|
|
*
|
|
|
|
* Once the child starts, DLLs loading in different order or threads getting
|
|
|
|
* scheduled differently may allocate memory which can conflict with the
|
|
|
|
* address space we need for our shared memory. By reserving the shared
|
|
|
|
* memory region before the child starts, and freeing it only just before we
|
|
|
|
* attempt to get access to the shared memory forces these allocations to
|
|
|
|
* be given different address ranges that don't conflict.
|
|
|
|
*
|
|
|
|
* NOTE! This function executes in the postmaster, and should for this
|
|
|
|
* reason not use elog(FATAL) since that would take down the postmaster.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pgwin32_ReserveSharedMemoryRegion(HANDLE hChild)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
void *address;
|
2009-07-24 22:12:42 +02:00
|
|
|
|
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
Assert(UsedShmemSegSize != 0);
|
|
|
|
|
|
|
|
address = VirtualAllocEx(hChild, UsedShmemSegAddr, UsedShmemSegSize,
|
2010-02-26 03:01:40 +01:00
|
|
|
MEM_RESERVE, PAGE_READWRITE);
|
|
|
|
if (address == NULL)
|
|
|
|
{
|
2009-07-24 22:12:42 +02:00
|
|
|
/* Don't use FATAL since we're running in the postmaster */
|
2011-08-23 21:00:52 +02:00
|
|
|
elog(LOG, "could not reserve shared memory region (addr=%p) for child %p: error code %lu",
|
2009-07-24 22:12:42 +02:00
|
|
|
UsedShmemSegAddr, hChild, GetLastError());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (address != UsedShmemSegAddr)
|
|
|
|
{
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Should never happen - in theory if allocation granularity causes
|
|
|
|
* strange effects it could, so check just in case.
|
2009-07-24 22:12:42 +02:00
|
|
|
*
|
|
|
|
* Don't use FATAL since we're running in the postmaster.
|
|
|
|
*/
|
2010-02-26 03:01:40 +01:00
|
|
|
elog(LOG, "reserved shared memory region got incorrect address %p, expected %p",
|
2009-07-24 22:12:42 +02:00
|
|
|
address, UsedShmemSegAddr);
|
|
|
|
VirtualFreeEx(hChild, address, 0, MEM_RELEASE);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|