• Tom Lane's avatar
    Use data directory inode number, not port, to select SysV resource keys. · 7de19fbc
    Tom Lane authored
    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
    7de19fbc
pg_shmem.h 2.66 KB