Re: Feature: POSIX Shared memory support - Mailing list pgsql-patches
From | Chris Marcellino |
---|---|
Subject | Re: Feature: POSIX Shared memory support |
Date | |
Msg-id | D35E1B28-3EF7-47F8-997F-857831EE2FDA@levelview.com Whole thread Raw |
In response to | Re: Feature: POSIX Shared memory support ("Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com>) |
Responses |
Re: Feature: POSIX Shared memory support
|
List | pgsql-patches |
Responses inline. On Feb 6, 2007, at 7:05 PM, Takayuki Tsunakawa wrote: > From: "Chris Marcellino" <maps@levelview.com> >> To this end, I have "ported" the svsv_shmem.c layer to use the POSIX >> calls (which are some ways more robust w.r.t reducing collision by >> using strings as shared memory id's, instead of ints). > > I hope your work will be accepted. Setting IPC parameters is tedious > for normal users, and they sometimes miss the manual article and hit > the IPC resource shortage problem, particularly when the system > developers run multiple instances on a single machine at the same > time. As Tom pointed out, the code I posted yesterday is not robust enough for general consumption. I'm working on a better solution, which will likely involve using a very small SysV shmem segment as a mutex of sorts (as Michael Paesold suggested). > Then, how about semaphores? When I just do configure, PostgreSQL > seems to use SysV semaphores. But POSIX semaphore implementation is > prepared in src/backend/port/posix_sema.c. Why isn't it used by > default? Does it have any problem? > In this case, semaphore usage is unrelated to shared memory shortages. Also, on many platforms the posix_sema's code is used. Either way, Essentially, no one is running out of shared memory due to semaphores. > # Windows is good in this point, isn't it? From what I can tell, if you look at the Windows SysV shmem emulation code in src/backend/port/win32/shmem.c, you will see in the shmctl() function that the 'other process detection' code is not implemented, since their is no corresponding Win32 API to implement this. There is only so much you can do in that case. As far as the other platforms go, any replacement for the SysV shmem code should be as reliable as what preceded it. > > I'm sorry to ask you a question even though I've not read your patch > well. Does mmap(MAP_SHARED) need msync() to make the change by one > process visible to other processes? I found the following in the > manual page of mmap on Linux: > > ------------------------------------------------------------ > MAP_SHARED Share this mapping with all other processes that > map this > object. Storing to the region is equivalent to writing to > the file. The file may not actually be updated until > msync(2) or munmap(2) are called. > ------------------------------------------------------------ > > BTW, is the number of semaphores for dummy backends (eg bgwriter, > autovacuum) counted in PostgreSQL manual? > > From: "Tom Lane" <tgl@sss.pgh.pa.us> >> the POSIX API provides no way to detect whether anyone else is > attached >> to the segment. Not being able to tell that is a tremendous > robustness >> hit for us. We are not going to risk destroying someone's database >> (or in the alternative, failing to restart after most crashes, which >> it looks like your patch would do) in order to make installation >> fractionally easier. > > How is this done on Windows? Is it possible to count the number of > processes that attach a shared memory? > > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings
pgsql-patches by date: