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
