On 2019-08-14 01:22, Tom Lane wrote: > Attached is a draft patch to change both shmem and sema key selection > to be based on data directory inode rather than port. > > I considered using "st_ino ^ st_dev", or some such, but decided that > that would largely just make it harder to manually correlate IPC > keys with running postmasters. It's generally easy to find out the > data directory inode number with "ls", but the extra work to find out > and XOR in the device number is not so easy, and it's not clear what > it'd buy us in typical scenarios.
For the POSIX APIs where the numbers are just converted to a string, why not use both -- or forget about the inodes and use the actual data directory string. For the SYSV APIs, the scenario that came to my mind is if someone starts a bunch of servers each on their own mount, it could happen that the inodes of the data directories are very similar. There is also the issue that AFAICT the key_t in the SYSV APIs is always 32-bit whereas inodes are 64-bit. Probably not a big deal, but it might prevent an exact one-to-one mapping. Of course, ftok() is also available here as an existing solution. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
