Re: shmem_seq may be a bad idea
От | Peter Eisentraut |
---|---|
Тема | Re: shmem_seq may be a bad idea |
Дата | |
Msg-id | Pine.GSO.4.02A.10005021037050.13753-100000@Iller.DoCS.UU.SE обсуждение исходный текст |
Ответ на | 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 |
On Mon, 1 May 2000, Tom Lane wrote: > > Why not use IPC_EXCL to ensure you're getting a freshly baked shmem > > segment rather than a recycled one? > > Hmm, that might work --- we'd need to add some logic to try to delete > a conflicting segment and/or move on to another key if we can't. How about you just pick a key (preferably using a standard method such as ftok, but the current is fine as well if you like the traceability of keys to servers) and if it's already used then increase it by one, try again. For efficiency you could keep the last key that worked in a global and start retrying from there. No need to try any fancy sequence number that wrap after 10 times anyway and thus don't help in general. A while ago while thinking about a way to make ipcclean better I thunk that perhaps the postmaster should write the keys of the segments it gets to a flat-text file. If it somehow crashes and loses track of what it allocated before it can use that information to clean up. Not sure how often that would take effect but it's very socially friendly. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: