From: "Chris Marcellino" <[EMAIL PROTECTED]>
> 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
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" <[EMAIL PROTECTED]>
> the POSIX API provides no way to detect whether anyone else is
> to the segment.  Not being able to tell that is a tremendous
> 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

Reply via email to