Tom Lane writes:
> The thing I don't like about using ftok() is that it opens you up to
> cross-postmaster conflicts, if there's more than one postmaster running
> on the same machine. Since ftok is so weakly specified, we have no way
> to be sure that two different postmasters wouldn't generate the same
> key.
The name ftok=file-to-key implies that the file name is being used to
create some fairly unique keys. All systems I peeked at used the inode and
device number of the file name you give it. Surely OS vendors could alias
ftok() to random(), but I'd like to give them a little credit at least.
But this is not the issue, I don't care what the key making scheme is. It
could in fact be random(). But you *must* use IPC_EXCL to check if the
segment already exists and change your key if so. If you do that then you
*never* have a conflict, no matter what you do. That should be a
no-brainer. Temporary files are handled this way as well (in theory
anyway).
> (Of course, if the postgres account also runs non-postgres applications
> that use shmem or semas, you could have trouble anyway ... but that
> seems unlikely, and perhaps more to the point it's pretty easy to avoid
> *as long as postgres generates predictable keys*.
But you still have to trust other applications to avoid the PostgreSQL key
space, which they probably couldn't care less about. The whole point of
this exercise is to increase fault-tolerance, so you shouldn't assume too
much about a sane environment.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
