2007-03-21 15:39:23 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* win32_shmem.c
|
|
|
|
* Implement shared memory using win32 facilities
|
|
|
|
*
|
2021-01-02 19:06:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2021, 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"
|
|
|
|
|
2019-04-09 06:39:00 +02:00
|
|
|
/*
|
|
|
|
* Early in a process's life, Windows asynchronously creates threads for the
|
|
|
|
* process's "default thread pool"
|
|
|
|
* (https://docs.microsoft.com/en-us/windows/desktop/ProcThread/thread-pools).
|
|
|
|
* Occasionally, thread creation allocates a stack after
|
|
|
|
* PGSharedMemoryReAttach() has released UsedShmemSegAddr and before it has
|
|
|
|
* mapped shared memory at UsedShmemSegAddr. This would cause mapping to fail
|
|
|
|
* if the allocator preferred the just-released region for allocating the new
|
|
|
|
* thread stack. We observed such failures in some Windows Server 2016
|
|
|
|
* configurations. To give the system another region to prefer, reserve and
|
|
|
|
* release an additional, protective region immediately before reserving or
|
|
|
|
* releasing shared memory. The idea is that, if the allocator handed out
|
|
|
|
* REGION1 pages before REGION2 pages at one occasion, it will do so whenever
|
|
|
|
* both regions are free. Windows Server 2016 exhibits that behavior, and a
|
|
|
|
* system behaving differently would have less need to protect
|
|
|
|
* UsedShmemSegAddr. The protective region must be at least large enough for
|
|
|
|
* one thread stack. However, ten times as much is less than 2% of the 32-bit
|
|
|
|
* address space and is negligible relative to the 64-bit address space.
|
|
|
|
*/
|
|
|
|
#define PROTECTIVE_REGION_SIZE (10 * WIN32_STACK_RLIMIT)
|
|
|
|
void *ShmemProtectiveRegion = 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
|
|
|
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());
|
|
|
|
|
2008-07-04 12:50:18 +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());
|
|
|
|
|
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
|
|
|
|
* causes permission errors in a lot of cases, so we leave it in the
|
|
|
|
* default namespace for now.
|
|
|
|
*/
|
|
|
|
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
|
|
|
|
* crashed, but it left child backends that are still running. Therefore
|
|
|
|
* 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)
|
|
|
|
{
|
|
|
|
HANDLE hToken;
|
|
|
|
TOKEN_PRIVILEGES tp;
|
|
|
|
LUID luid;
|
|
|
|
|
|
|
|
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
|
|
|
|
{
|
|
|
|
ereport(elevel,
|
2021-02-04 13:31:13 +01:00
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu",
|
2021-05-12 19:14:10 +02:00
|
|
|
|
2021-02-04 13:31:13 +01:00
|
|
|
/*
|
|
|
|
* translator: This is a term from Windows and should be translated to
|
|
|
|
* match the Windows localization.
|
|
|
|
*/
|
|
|
|
_("Lock pages in memory"),
|
|
|
|
GetLastError()),
|
2018-01-21 15:40:46 +01:00
|
|
|
errdetail("Failed system call was %s.", "OpenProcessToken")));
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!LookupPrivilegeValue(NULL, SE_LOCK_MEMORY_NAME, &luid))
|
|
|
|
{
|
|
|
|
ereport(elevel,
|
2021-02-04 13:31:13 +01:00
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu", _("Lock pages in memory"), GetLastError()),
|
2018-01-21 15:40:46 +01:00
|
|
|
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,
|
2021-02-04 13:31:13 +01:00
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu", _("Lock pages in memory"), GetLastError()),
|
2018-01-21 15:40:46 +01:00
|
|
|
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),
|
2021-02-04 13:31:13 +01:00
|
|
|
errmsg("could not enable user right \"%s\"", _("Lock pages in memory")),
|
|
|
|
errhint("Assign user right \"%s\" to the Windows user account which runs PostgreSQL.",
|
|
|
|
_("Lock pages in memory"))));
|
2018-01-21 15:40:46 +01:00
|
|
|
else
|
|
|
|
ereport(elevel,
|
2021-02-04 13:31:13 +01:00
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu", _("Lock pages in memory"), GetLastError()),
|
2018-01-21 15:40:46 +01:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
PGShmemHeader *
|
Use data directory inode number, not port, to select SysV resource keys.
This approach provides a much tighter binding between a data directory
and the associated SysV shared memory block (and SysV or named-POSIX
semaphores, if we're using those). Key collisions are still possible,
but only between data directories stored on different filesystems,
so the situation should be negligible in practice. More importantly,
restarting the postmaster with a different port number no longer
risks failing to identify a relevant shared memory block, even when
postmaster.pid has been removed. A standalone backend is likewise
much more certain to detect conflicting leftover backends.
(In the longer term, we might now think about deprecating the port as
a cluster-wide value, so that one postmaster could support sockets
with varying port numbers. But that's for another day.)
The hazards fixed here apply only on Unix systems; our Windows code
paths already use identifiers derived from the data directory path
name rather than the port.
src/test/recovery/t/017_shm.pl, which intends to test key-collision
cases, has been substantially rewritten since it can no longer use
two postmasters with identical port numbers to trigger the case.
Instead, use Perl's IPC::SharedMem module to create a conflicting
shmem segment directly. The test script will be skipped if that
module is not available. (This means that some older buildfarm
members won't run it, but I don't think that that results in any
meaningful coverage loss.)
Patch by me; thanks to Noah Misch and Peter Eisentraut for discussion
and review.
Discussion: https://postgr.es/m/16908.1557521200@sss.pgh.pa.us
2019-09-05 19:31:41 +02:00
|
|
|
PGSharedMemoryCreate(Size size,
|
2014-04-08 17:39:55 +02:00
|
|
|
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
|
|
|
|
2019-04-09 06:39:00 +02:00
|
|
|
ShmemProtectiveRegion = VirtualAlloc(NULL, PROTECTIVE_REGION_SIZE,
|
|
|
|
MEM_RESERVE, PAGE_NOACCESS);
|
|
|
|
if (ShmemProtectiveRegion == NULL)
|
|
|
|
elog(FATAL, "could not reserve memory region: error code %lu",
|
|
|
|
GetLastError());
|
|
|
|
|
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,
|
2021-02-17 11:24:46 +01:00
|
|
|
(errmsg_internal("disabling huge pages")));
|
2018-01-21 15:40:46 +01:00
|
|
|
}
|
|
|
|
else if (!EnableLockPagesPrivilege(huge_pages == HUGE_PAGES_ON ? FATAL : DEBUG1))
|
|
|
|
{
|
|
|
|
ereport(DEBUG1,
|
2021-02-17 11:24:46 +01:00
|
|
|
(errmsg_internal("disabling huge pages")));
|
2018-01-21 15:40:46 +01:00
|
|
|
}
|
|
|
|
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
|
|
|
|
* 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-05-04 10:36:40 +02:00
|
|
|
/*
|
|
|
|
* In case CreateFileMapping() doesn't set the error code to 0 on
|
|
|
|
* success
|
|
|
|
*/
|
|
|
|
SetLastError(0);
|
|
|
|
|
2010-01-02 13:18:45 +01:00
|
|
|
hmap = CreateFileMapping(INVALID_HANDLE_VALUE, /* Use the pagefile */
|
2009-05-05 11:48:51 +02:00
|
|
|
NULL, /* Default security attrs */
|
2018-01-21 15:40:46 +01:00
|
|
|
flProtect,
|
2010-01-02 13:18:45 +01: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);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use the original size, not the rounded-up value, when
|
|
|
|
* falling back to non-huge pages.
|
|
|
|
*/
|
|
|
|
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-05-05 23:51:46 +02:00
|
|
|
CloseHandle(hmap); /* Close the handle, since we got a valid one
|
2009-05-05 11:48:51 +02:00
|
|
|
* 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,
|
|
|
|
(errmsg("pre-existing shared memory block is still in use"),
|
|
|
|
errhint("Check if there are any old server processes still running, and terminate them.")));
|
|
|
|
|
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
|
|
|
*
|
2019-04-09 06:39:00 +02:00
|
|
|
* ShmemProtectiveRegion, UsedShmemSegID and UsedShmemSegAddr are implicit
|
|
|
|
* parameters to this routine. The caller must have already restored them to
|
|
|
|
* the postmaster's values.
|
2007-03-21 15:39:23 +01:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
PGSharedMemoryReAttach(void)
|
|
|
|
{
|
|
|
|
PGShmemHeader *hdr;
|
|
|
|
void *origUsedShmemSegAddr = UsedShmemSegAddr;
|
|
|
|
|
2019-04-09 06:39:00 +02:00
|
|
|
Assert(ShmemProtectiveRegion != NULL);
|
2007-03-21 15:39:23 +01:00
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
Assert(IsUnderPostmaster);
|
|
|
|
|
2009-07-24 22:12:42 +02:00
|
|
|
/*
|
2019-04-09 06:39:00 +02:00
|
|
|
* Release memory region reservations made by the postmaster
|
2009-07-24 22:12:42 +02:00
|
|
|
*/
|
2019-04-09 06:39:00 +02:00
|
|
|
if (VirtualFree(ShmemProtectiveRegion, 0, MEM_RELEASE) == 0)
|
|
|
|
elog(FATAL, "failed to release reserved memory region (addr=%p): error code %lu",
|
|
|
|
ShmemProtectiveRegion, GetLastError());
|
2009-07-24 22:12:42 +02:00
|
|
|
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.
|
|
|
|
*
|
2019-04-09 06:39:00 +02:00
|
|
|
* ShmemProtectiveRegion, UsedShmemSegID and UsedShmemSegAddr are implicit
|
|
|
|
* parameters to this routine. The caller must have already restored them to
|
|
|
|
* the postmaster's values.
|
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
|
|
|
*/
|
|
|
|
void
|
|
|
|
PGSharedMemoryNoReAttach(void)
|
|
|
|
{
|
2019-04-09 06:39:00 +02:00
|
|
|
Assert(ShmemProtectiveRegion != 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
|
|
|
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.
|
|
|
|
*
|
2019-04-09 06:39:00 +02:00
|
|
|
* ShmemProtectiveRegion, UsedShmemSegID and UsedShmemSegAddr are implicit
|
|
|
|
* parameters to this routine.
|
2007-03-21 15:39:23 +01:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
PGSharedMemoryDetach(void)
|
|
|
|
{
|
2019-04-09 06:39:00 +02:00
|
|
|
/*
|
|
|
|
* Releasing the protective region liberates an unimportant quantity of
|
|
|
|
* address space, but be tidy.
|
|
|
|
*/
|
|
|
|
if (ShmemProtectiveRegion != NULL)
|
|
|
|
{
|
|
|
|
if (VirtualFree(ShmemProtectiveRegion, 0, MEM_RELEASE) == 0)
|
|
|
|
elog(LOG, "failed to release reserved memory region (addr=%p): error code %lu",
|
|
|
|
ShmemProtectiveRegion, GetLastError());
|
|
|
|
|
|
|
|
ShmemProtectiveRegion = 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
|
|
|
/* 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)
|
|
|
|
{
|
|
|
|
void *address;
|
|
|
|
|
2019-04-09 06:39:00 +02:00
|
|
|
Assert(ShmemProtectiveRegion != NULL);
|
2009-07-24 22:12:42 +02:00
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
Assert(UsedShmemSegSize != 0);
|
|
|
|
|
2019-04-09 06:39:00 +02:00
|
|
|
/* ShmemProtectiveRegion */
|
|
|
|
address = VirtualAllocEx(hChild, ShmemProtectiveRegion,
|
|
|
|
PROTECTIVE_REGION_SIZE,
|
|
|
|
MEM_RESERVE, PAGE_NOACCESS);
|
2009-07-24 22:12:42 +02:00
|
|
|
if (address == NULL)
|
|
|
|
{
|
|
|
|
/* 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",
|
2019-04-09 06:39:00 +02:00
|
|
|
ShmemProtectiveRegion, hChild, GetLastError());
|
2009-07-24 22:12:42 +02:00
|
|
|
return false;
|
|
|
|
}
|
2019-04-09 06:39:00 +02:00
|
|
|
if (address != ShmemProtectiveRegion)
|
2009-07-24 22:12:42 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Should never happen - in theory if allocation granularity causes
|
|
|
|
* strange effects it could, so check just in case.
|
|
|
|
*
|
|
|
|
* Don't use FATAL since we're running in the postmaster.
|
|
|
|
*/
|
2019-04-09 06:39:00 +02:00
|
|
|
elog(LOG, "reserved shared memory region got incorrect address %p, expected %p",
|
|
|
|
address, ShmemProtectiveRegion);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* UsedShmemSegAddr */
|
|
|
|
address = VirtualAllocEx(hChild, UsedShmemSegAddr, UsedShmemSegSize,
|
|
|
|
MEM_RESERVE, PAGE_READWRITE);
|
|
|
|
if (address == NULL)
|
|
|
|
{
|
|
|
|
elog(LOG, "could not reserve shared memory region (addr=%p) for child %p: error code %lu",
|
|
|
|
UsedShmemSegAddr, hChild, GetLastError());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (address != UsedShmemSegAddr)
|
|
|
|
{
|
2009-07-24 22:12:42 +02:00
|
|
|
elog(LOG, "reserved shared memory region got incorrect address %p, expected %p",
|
|
|
|
address, UsedShmemSegAddr);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|