Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

src

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    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
    a74740fb
    History
    Name Last commit Last update
    ..