Re: Feature: POSIX Shared memory support - Mailing list pgsql-patches

From Takayuki Tsunakawa
Subject Re: Feature: POSIX Shared memory support
Date
Msg-id 027c01c74a64$d3789ab0$19527c0a@OPERAO
Whole thread Raw
In response to Feature: POSIX Shared memory support  (Chris Marcellino <maps@levelview.com>)
Responses Re: Feature: POSIX Shared memory support  (Chris Marcellino <maps@levelview.com>)
Re: Feature: POSIX Shared memory support  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
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.
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?
# Windows is good in this point, isn't 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?




pgsql-patches by date:

Previous
From: "FAST PostgreSQL"
Date:
Subject: Re: [pgsql-patches] pg_get_domaindef
Next
From: Chris Marcellino
Date:
Subject: Re: Feature: POSIX Shared memory support