Re: shmem_seq may be a bad idea
От | Peter Eisentraut |
---|---|
Тема | Re: shmem_seq may be a bad idea |
Дата | |
Msg-id | Pine.LNX.4.21.0005030036330.362-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: shmem_seq may be a bad idea (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: shmem_seq may be a bad idea
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: