Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
Oh, I agree that IPC_EXCL would be an improvement. I'm just dubious
that using ftok() is an improvement.
>> 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.
Yup, that's what I would have expected from the way it's described in
the man page. My point is you can't put more than 32 bits of stuff in
a 32-bit sack; therefore, ftok cannot guarantee that it delivers a
distinct token for every combination of inode + device + application
key. I doubt it even tries very hard, more likely just xor's them
together and trusts to luck. So I'd rather use a predictable mapping
that we *know* will not generate cross-postmaster conflicts between
postmasters running concurrently on different ports.
However, IPC_EXCL would definitely make us more robust against other
sorts of conflicts, so I agree that's a good change to make. TODO
list entry, please, Bruce?
* Use IPC_EXCL when creating shared memory and semaphores
regards, tom lane
