|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* win32_shmem.c
|
|
|
|
|
* Implement shared memory using win32 facilities
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
|
|
|
|
*
|
|
|
|
|
* IDENTIFICATION
|
|
|
|
|
* src/backend/port/win32_shmem.c
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
|
|
#include "miscadmin.h"
|
|
|
|
|
#include "storage/dsm.h"
|
|
|
|
|
#include "storage/ipc.h"
|
|
|
|
|
#include "storage/pg_shmem.h"
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
#include "utils/guc_hooks.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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
10 years ago
|
|
|
HANDLE UsedShmemSegID = INVALID_HANDLE_VALUE;
|
|
|
|
|
void *UsedShmemSegAddr = NULL;
|
|
|
|
|
static Size UsedShmemSegSize = 0;
|
|
|
|
|
|
|
|
|
|
static bool EnableLockPagesPrivilege(int elevel);
|
|
|
|
|
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)
|
|
|
|
|
elog(FATAL, "could not get size for full pathname of datadir %s: error code %lu",
|
|
|
|
|
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
9 years ago
|
|
|
retptr = malloc(bufsize + 18); /* 18 for Global\PostgreSQL: */
|
|
|
|
|
if (retptr == NULL)
|
|
|
|
|
elog(FATAL, "could not allocate memory for shared memory name");
|
|
|
|
|
|
|
|
|
|
strcpy(retptr, "Global\\PostgreSQL:");
|
|
|
|
|
r = GetFullPathName(DataDir, bufsize, retptr + 18, NULL);
|
|
|
|
|
if (r == 0 || r > bufsize)
|
|
|
|
|
elog(FATAL, "could not generate full pathname for datadir %s: error code %lu",
|
|
|
|
|
DataDir, GetLastError());
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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++)
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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,
|
|
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu",
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* translator: This is a term from Windows and should be translated to
|
|
|
|
|
* match the Windows localization.
|
|
|
|
|
*/
|
|
|
|
|
_("Lock pages in memory"),
|
|
|
|
|
GetLastError()),
|
|
|
|
|
errdetail("Failed system call was %s.", "OpenProcessToken")));
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!LookupPrivilegeValue(NULL, SE_LOCK_MEMORY_NAME, &luid))
|
|
|
|
|
{
|
|
|
|
|
ereport(elevel,
|
|
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu", _("Lock pages in memory"), 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 user right \"%s\": error code %lu", _("Lock pages in memory"), 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 user right \"%s\"", _("Lock pages in memory")),
|
|
|
|
|
errhint("Assign user right \"%s\" to the Windows user account which runs PostgreSQL.",
|
|
|
|
|
_("Lock pages in memory"))));
|
|
|
|
|
else
|
|
|
|
|
ereport(elevel,
|
|
|
|
|
(errmsg("could not enable user right \"%s\": error code %lu", _("Lock pages in memory"), GetLastError()),
|
|
|
|
|
errdetail("Failed system call was %s.", "AdjustTokenPrivileges")));
|
|
|
|
|
CloseHandle(hToken);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CloseHandle(hToken);
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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
6 years ago
|
|
|
PGSharedMemoryCreate(Size size,
|
|
|
|
|
PGShmemHeader **shim)
|
|
|
|
|
{
|
|
|
|
|
void *memAddress;
|
|
|
|
|
PGShmemHeader *hdr;
|
|
|
|
|
HANDLE hmap,
|
|
|
|
|
hmap2;
|
|
|
|
|
char *szShareMem;
|
|
|
|
|
int i;
|
|
|
|
|
DWORD size_high;
|
|
|
|
|
DWORD size_low;
|
|
|
|
|
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.
12 years ago
|
|
|
|
|
|
|
|
ShmemProtectiveRegion = VirtualAlloc(NULL, PROTECTIVE_REGION_SIZE,
|
|
|
|
|
MEM_RESERVE, PAGE_NOACCESS);
|
|
|
|
|
if (ShmemProtectiveRegion == NULL)
|
|
|
|
|
elog(FATAL, "could not reserve memory region: error code %lu",
|
|
|
|
|
GetLastError());
|
|
|
|
|
|
|
|
|
|
/* Room for a header? */
|
|
|
|
|
Assert(size > MAXALIGN(sizeof(PGShmemHeader)));
|
|
|
|
|
|
|
|
|
|
szShareMem = GetSharedMemName();
|
|
|
|
|
|
|
|
|
|
UsedShmemSegAddr = NULL;
|
|
|
|
|
|
|
|
|
|
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_internal("disabling huge pages")));
|
|
|
|
|
}
|
|
|
|
|
else if (!EnableLockPagesPrivilege(huge_pages == HUGE_PAGES_ON ? FATAL : DEBUG1))
|
|
|
|
|
{
|
|
|
|
|
ereport(DEBUG1,
|
|
|
|
|
(errmsg_internal("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:
|
|
|
|
|
#ifdef _WIN64
|
|
|
|
|
size_high = size >> 32;
|
|
|
|
|
#else
|
|
|
|
|
size_high = 0;
|
|
|
|
|
#endif
|
|
|
|
|
size_low = (DWORD) size;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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)
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < 10; i++)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* In case CreateFileMapping() doesn't set the error code to 0 on
|
|
|
|
|
* success
|
|
|
|
|
*/
|
|
|
|
|
SetLastError(0);
|
|
|
|
|
|
|
|
|
|
hmap = CreateFileMapping(INVALID_HANDLE_VALUE, /* Use the pagefile */
|
|
|
|
|
NULL, /* Default security attrs */
|
|
|
|
|
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
9 years ago
|
|
|
size_high, /* Size Upper 32 Bits */
|
|
|
|
|
size_low, /* Size Lower 32 bits */
|
|
|
|
|
szShareMem);
|
|
|
|
|
|
|
|
|
|
if (!hmap)
|
|
|
|
|
{
|
|
|
|
|
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)));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the segment already existed, CreateFileMapping() will return a
|
|
|
|
|
* handle to the existing one and set ERROR_ALREADY_EXISTS.
|
|
|
|
|
*/
|
|
|
|
|
if (GetLastError() == ERROR_ALREADY_EXISTS)
|
|
|
|
|
{
|
|
|
|
|
CloseHandle(hmap); /* Close the handle, since we got a valid one
|
|
|
|
|
* to the previous segment. */
|
|
|
|
|
hmap = NULL;
|
|
|
|
|
Sleep(1000);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
if (!hmap)
|
|
|
|
|
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.")));
|
|
|
|
|
|
|
|
|
|
free(szShareMem);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Make the handle inheritable
|
|
|
|
|
*/
|
|
|
|
|
if (!DuplicateHandle(GetCurrentProcess(), hmap, GetCurrentProcess(), &hmap2, 0, TRUE, DUPLICATE_SAME_ACCESS))
|
|
|
|
|
ereport(FATAL,
|
|
|
|
|
(errmsg("could not create shared memory segment: error code %lu", GetLastError()),
|
|
|
|
|
errdetail("Failed system call was DuplicateHandle.")));
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Close the old, non-inheritable handle. If this fails we don't really
|
|
|
|
|
* care.
|
|
|
|
|
*/
|
|
|
|
|
if (!CloseHandle(hmap))
|
|
|
|
|
elog(LOG, "could not close handle to shared memory: error code %lu", GetLastError());
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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,
|
|
|
|
|
(errmsg("could not create shared memory segment: error code %lu", GetLastError()),
|
|
|
|
|
errdetail("Failed system call was MapViewOfFileEx.")));
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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));
|
|
|
|
|
hdr->dsm_control = 0;
|
|
|
|
|
|
|
|
|
|
/* Save info for possible future use */
|
|
|
|
|
UsedShmemSegAddr = memAddress;
|
|
|
|
|
UsedShmemSegSize = size;
|
|
|
|
|
UsedShmemSegID = hmap2;
|
|
|
|
|
|
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
10 years ago
|
|
|
/* Register on-exit routine to delete the new segment */
|
|
|
|
|
on_shmem_exit(pgwin32_SharedMemoryDelete, PointerGetDatum(hmap2));
|
|
|
|
|
|
|
|
|
|
*shim = hdr;
|
|
|
|
|
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
10 years ago
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* ShmemProtectiveRegion, 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(ShmemProtectiveRegion != NULL);
|
|
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
|
Assert(IsUnderPostmaster);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Release memory region reservations made by the postmaster
|
|
|
|
|
*/
|
|
|
|
|
if (VirtualFree(ShmemProtectiveRegion, 0, MEM_RELEASE) == 0)
|
|
|
|
|
elog(FATAL, "failed to release reserved memory region (addr=%p): error code %lu",
|
|
|
|
|
ShmemProtectiveRegion, GetLastError());
|
|
|
|
|
if (VirtualFree(UsedShmemSegAddr, 0, MEM_RELEASE) == 0)
|
|
|
|
|
elog(FATAL, "failed to release reserved memory region (addr=%p): error code %lu",
|
|
|
|
|
UsedShmemSegAddr, GetLastError());
|
|
|
|
|
|
|
|
|
|
hdr = (PGShmemHeader *) MapViewOfFileEx(UsedShmemSegID, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0, UsedShmemSegAddr);
|
|
|
|
|
if (!hdr)
|
|
|
|
|
elog(FATAL, "could not reattach to shared memory (key=%p, addr=%p): error code %lu",
|
|
|
|
|
UsedShmemSegID, UsedShmemSegAddr, GetLastError());
|
|
|
|
|
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");
|
|
|
|
|
dsm_set_control_handle(hdr->dsm_control);
|
|
|
|
|
|
|
|
|
|
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
10 years ago
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* 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
10 years ago
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
PGSharedMemoryNoReAttach(void)
|
|
|
|
|
{
|
|
|
|
|
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
10 years ago
|
|
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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
10 years ago
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* ShmemProtectiveRegion, UsedShmemSegID and UsedShmemSegAddr are implicit
|
|
|
|
|
* parameters to this routine.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
PGSharedMemoryDetach(void)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* 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
10 years ago
|
|
|
/* Unmap the view, if it's mapped */
|
|
|
|
|
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
10 years ago
|
|
|
elog(LOG, "could not unmap view of shared memory: error code %lu",
|
|
|
|
|
GetLastError());
|
|
|
|
|
|
|
|
|
|
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
10 years ago
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
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
10 years ago
|
|
|
* pgwin32_SharedMemoryDelete
|
|
|
|
|
*
|
|
|
|
|
* Detach from and delete the shared memory segment
|
|
|
|
|
* (called as an on_shmem_exit callback, hence funny argument list)
|
|
|
|
|
*/
|
|
|
|
|
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
10 years ago
|
|
|
Assert(DatumGetPointer(shmId) == UsedShmemSegID);
|
|
|
|
|
PGSharedMemoryDetach();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
|
|
Assert(ShmemProtectiveRegion != NULL);
|
|
|
|
|
Assert(UsedShmemSegAddr != NULL);
|
|
|
|
|
Assert(UsedShmemSegSize != 0);
|
|
|
|
|
|
|
|
|
|
/* ShmemProtectiveRegion */
|
|
|
|
|
address = VirtualAllocEx(hChild, ShmemProtectiveRegion,
|
|
|
|
|
PROTECTIVE_REGION_SIZE,
|
|
|
|
|
MEM_RESERVE, PAGE_NOACCESS);
|
|
|
|
|
if (address == NULL)
|
|
|
|
|
{
|
|
|
|
|
/* Don't use FATAL since we're running in the postmaster */
|
|
|
|
|
elog(LOG, "could not reserve shared memory region (addr=%p) for child %p: error code %lu",
|
|
|
|
|
ShmemProtectiveRegion, hChild, GetLastError());
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (address != ShmemProtectiveRegion)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
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)
|
|
|
|
|
{
|
|
|
|
|
elog(LOG, "reserved shared memory region got incorrect address %p, expected %p",
|
|
|
|
|
address, UsedShmemSegAddr);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This function is provided for consistency with sysv_shmem.c and does not
|
|
|
|
|
* provide any useful information for Windows. To obtain the large page size,
|
|
|
|
|
* use GetLargePageMinimum() instead.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
GetHugePageSize(Size *hugepagesize, int *mmap_flags)
|
|
|
|
|
{
|
|
|
|
|
if (hugepagesize)
|
|
|
|
|
*hugepagesize = 0;
|
|
|
|
|
if (mmap_flags)
|
|
|
|
|
*mmap_flags = 0;
|
|
|
|
|
}
|
Split up guc.c for better build speed and ease of maintenance.
guc.c has grown to be one of our largest .c files, making it
a bottleneck for compilation. It's also acquired a bunch of
knowledge that'd be better kept elsewhere, because of our not
very good habit of putting variable-specific check hooks here.
Hence, split it up along these lines:
* guc.c itself retains just the core GUC housekeeping mechanisms.
* New file guc_funcs.c contains the SET/SHOW interfaces and some
SQL-accessible functions for GUC manipulation.
* New file guc_tables.c contains the data arrays that define the
built-in GUC variables, along with some already-exported constant
tables.
* GUC check/assign/show hook functions are moved to the variable's
home module, whenever that's clearly identifiable. A few hard-
to-classify hooks ended up in commands/variable.c, which was
already a home for miscellaneous GUC hook functions.
To avoid cluttering a lot more header files with #include "guc.h",
I also invented a new header file utils/guc_hooks.h and put all
the GUC hook functions' declarations there, regardless of their
originating module. That allowed removal of #include "guc.h"
from some existing headers. The fallout from that (hopefully
all caught here) demonstrates clearly why such inclusions are
best minimized: there are a lot of files that, for example,
were getting array.h at two or more levels of remove, despite
not having any connection at all to GUCs in themselves.
There is some very minor code beautification here, such as
renaming a couple of inconsistently-named hook functions
and improving some comments. But mostly this just moves
code from point A to point B and deals with the ensuing
needs for #include adjustments and exporting a few functions
that previously weren't exported.
Patch by me, per a suggestion from Andres Freund; thanks also
to Michael Paquier for the idea to invent guc_funcs.c.
Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
3 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* GUC check_hook for huge_page_size
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
check_huge_page_size(int *newval, void **extra, GucSource source)
|
|
|
|
|
{
|
|
|
|
|
if (*newval != 0)
|
|
|
|
|
{
|
|
|
|
|
GUC_check_errdetail("huge_page_size must be 0 on this platform.");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|