I wrote: > Will go fix/backpatch in a minute. Done now, but while thinking more about the issue, I had an idea: why is it that we base the shmem key on the postmaster's port number, and not on the data directory's inode number? Using the port number not only increases the risk of collisions (though admittedly only in testing situations), but it *decreases* our ability to detect real conflicts. Consider case where DBA wants to change the installation's port number, and he edits postgresql.conf, but then uses "kill -9 && rm postmaster.pid" rather than some saner way of stopping the old postmaster. When he starts the new one, it won't detect any remaining children of the old postmaster because it'll be looking in the wrong range of shmem keys. It seems like something tied to the data directory's identity would be much more trustworthy.
I think the reason for doing it this way originally was to allow one to identify which shmem segment is which in "ipcs -m" output. But that was back when having to clean up shmem segments manually was still a common task. It's been a long time since I can remember needing to figure out which was which. regards, tom lane