summaryrefslogtreecommitdiff
path: root/configure.in
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-04-15 17:27:38 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-04-15 17:28:08 -0400
commit07a990c6e7d151244199f443753f7e15df32e010 (patch)
tree6635fdc2361c1413a4468533a7f4d9c63a5459a8 /configure.in
parente0eda580d23da747e89ec8355d6094eb4557abfe (diff)
downloadpostgresql-07a990c6e7d151244199f443753f7e15df32e010.tar.gz
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 what address the kernel chooses to map the shared memory segment at. However, when building with EXEC_BACKEND, there's a risk that the chosen address won't be available in all child processes. Linux with ASLR enabled (which it is by default) seems particularly at risk because it puts shmem segments into the same area where it maps shared libraries. We can work around that by specifying a mapping address that's outside the range where shared libraries could get mapped. On x86_64 Linux, 0x7e0000000000 seems to work well. This is only meant for testing/debugging purposes, so it doesn't seem necessary to go as far as providing a GUC (or any user-visible documentation, though we might change that later). Instead, it's just controlled by setting an environment variable PG_SHMEM_ADDR to the desired attach address. Back-patch to all supported branches, since the point here is to remove intermittent buildfarm failures on EXEC_BACKEND animals. Owners of affected animals will need to add a suitable setting of PG_SHMEM_ADDR to their build_env configuration. Discussion: https://postgr.es/m/7036.1492231361@sss.pgh.pa.us
Diffstat (limited to 'configure.in')
0 files changed, 0 insertions, 0 deletions