Re: shmem_seq may be a bad idea

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