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:

Previous
From: "Takayuki Tsunakawa"
Date:
Subject: Re: Feature: POSIX Shared memory support
Next
From: Tom Lane
Date:
Subject: Re: Feature: POSIX Shared memory support