From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: shmem_seq may be a bad idea |
Date: | 2000-05-04 00:42:48 |
Message-ID: | 18478.957400968@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-05-04 01:05:08 | RE: psql \l error |
Previous Message | Andrew McMillan | 2000-05-03 23:53:39 | Re: Why Not MySQL? |