Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitfddc101

Browse files
committed
Provide a way to control SysV shmem attach address in EXEC_BACKEND builds.
In standard non-Windows builds, there's no particular reason to care whataddress the kernel chooses to map the shared memory segment at. However,when building with EXEC_BACKEND, there's a risk that the chosen addresswon't be available in all child processes. Linux with ASLR enabled (whichit is by default) seems particularly at risk because it puts shmem segmentsinto the same area where it maps shared libraries. We can work aroundthat by specifying a mapping address that's outside the range whereshared libraries could get mapped. On x86_64 Linux, 0x7e0000000000seems to work well.This is only meant for testing/debugging purposes, so it doesn't seemnecessary to go as far as providing a GUC (or any user-visibledocumentation, though we might change that later). Instead, it's justcontrolled by setting an environment variable PG_SHMEM_ADDR to thedesired attach address.Back-patch to all supported branches, since the point here is toremove intermittent buildfarm failures on EXEC_BACKEND animals.Owners of affected animals will need to add a suitable setting ofPG_SHMEM_ADDR to their build_env configuration.Discussion:https://postgr.es/m/7036.1492231361@sss.pgh.pa.us
1 parentfad06b2 commitfddc101

File tree

1 file changed

+23
-2
lines changed

1 file changed

+23
-2
lines changed

‎src/backend/port/sysv_shmem.c

Lines changed: 23 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -90,8 +90,28 @@ static void *
9090
InternalIpcMemoryCreate(IpcMemoryKeymemKey,Sizesize)
9191
{
9292
IpcMemoryIdshmid;
93+
void*requestedAddress=NULL;
9394
void*memAddress;
9495

96+
/*
97+
* Normally we just pass requestedAddress = NULL to shmat(), allowing the
98+
* system to choose where the segment gets mapped. But in an EXEC_BACKEND
99+
* build, it's possible for whatever is chosen in the postmaster to not
100+
* work for backends, due to variations in address space layout. As a
101+
* rather klugy workaround, allow the user to specify the address to use
102+
* via setting the environment variable PG_SHMEM_ADDR. (If this were of
103+
* interest for anything except debugging, we'd probably create a cleaner
104+
* and better-documented way to set it, such as a GUC.)
105+
*/
106+
#ifdefEXEC_BACKEND
107+
{
108+
char*pg_shmem_addr=getenv("PG_SHMEM_ADDR");
109+
110+
if (pg_shmem_addr)
111+
requestedAddress= (void*)strtoul(pg_shmem_addr,NULL,0);
112+
}
113+
#endif
114+
95115
shmid=shmget(memKey,size,IPC_CREAT |IPC_EXCL |IPCProtection);
96116

97117
if (shmid<0)
@@ -191,10 +211,11 @@ InternalIpcMemoryCreate(IpcMemoryKey memKey, Size size)
191211
on_shmem_exit(IpcMemoryDelete,Int32GetDatum(shmid));
192212

193213
/* OK, should be able to attach to the segment */
194-
memAddress=shmat(shmid,NULL,PG_SHMAT_FLAGS);
214+
memAddress=shmat(shmid,requestedAddress,PG_SHMAT_FLAGS);
195215

196216
if (memAddress== (void*)-1)
197-
elog(FATAL,"shmat(id=%d) failed: %m",shmid);
217+
elog(FATAL,"shmat(id=%d, addr=%p, flags=0x%x) failed: %m",
218+
shmid,requestedAddress,PG_SHMAT_FLAGS);
198219

199220
/* Register on-exit routine to detach new segment before deleting */
200221
on_shmem_exit(IpcMemoryDetach,PointerGetDatum(memAddress));

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp