On 9/5/19 1:32 PM, Tom Lane wrote:
> 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
>
This has caused the 017_shm.pl tests to be skipped on jacana and
bowerbird, and to fail completely on my msys2 test system where the Perl
has the relevant IPC:: modules, unlike the buildfarm animals.
Maybe we need to fall back on the older code on Windows?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
