Re: POSIX shared memory support
От | Chris Marcellino |
---|---|
Тема | Re: POSIX shared memory support |
Дата | |
Msg-id | F2E8E75C-100C-49FB-A04D-66A29F1BDA9D@apple.com обсуждение исходный текст |
Ответ на | Re: POSIX shared memory support (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-patches |
I believe that all we need is the ID to be constant and unique while the postmaster or its associated backends are running. If anything from a given generation has the database open, it will remain constant before any new process can connect to it successfully. Would it be feasible to lookup the ID of an important file in the DataDir? As far as the POSIX version goes, here is an updated patch. I changed it to use the inode/device ID instead of the filename to avoid the renaming cases. It also no longer needs the more clunky than necessary hash stuff. (The NetBSD/OpenBSD patches are to force those to build with the SysV shmem calls, since they are notably without POSIX shmem support.) Thanks, Chris Marcellino On Feb 27, 2007, at 1:40 AM, Magnus Hagander wrote: > On Tue, Feb 27, 2007 at 10:30:15AM +0100, Magnus Hagander wrote: >>> Does Windows have a method to get a unique ID number for a given >>> data >>> directory, or a token file in that directory? It would need to be >>> constant while the database is open. Perhaps >>> GetFileInformationByHandle? It returns a struct with a nFileIndex >>> value that seems to be that, although I'm not certain. >>> This might make it easier to avoid the complexity of fitting the >>> filename in the segment name, and avoid the rename problem, >> >> Yes, you could use the fileindex value. You need that one and the >> volume >> serial number, total of 64+32 bits of data. >> >> So yeah, we cuold use that instead of the full path name if we >> want to. >> The advantage of this one is that it's shorter, the advantage of the >> full path name is that you can see where the backend is from. >> >> However, in most cases you will be able to see where the backend >> is from >> anyway, because it is likely to have some other file open in the data >> directory, so maybe that isn't such a big point after all? > > Actually, I'm not sure we can. It's only stable as long as someone has > the file open. It will change if it's closed and re-opened later. > > Given that we don't actually open the directory, and only files inside > it, I don't know how that works. > > //Magnus > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
Вложения
В списке pgsql-patches по дате отправления: