The original patch author:
Chris Marcellino <[EMAIL PROTECTED]>
was not CC'ed as part of this email thread. That was a mistake. Chris,
the email thread discussing your patch is here:
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01262.php
Please read the discussion -
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > James Mansion wrote:
> >> (confused) Why can't you use mmap of /dev/zero and inherit the fd
> >> into child processes?
>
> > This is what we do on win32 today. We don't use the sysv emulation
> > layer anymore.
>
> Did we ever find
Magnus Hagander <[EMAIL PROTECTED]> writes:
> James Mansion wrote:
>> (confused) Why can't you use mmap of /dev/zero and inherit the fd
>> into child processes?
> This is what we do on win32 today. We don't use the sysv emulation
> layer anymore.
Did we ever find an interlock that makes the win32
James Mansion wrote:
> Tom Lane wrote:
> > Yeah, I would be far more interested in this patch if it avoided
> > needing SysV shmem at all. The problem is to find an adequate
> > substitute for the nattch-based interlock against live children of
> > a dead postmaster.
> >
> >
> (confused) Why ca
Stephen Frost <[EMAIL PROTECTED]> writes:
> Right, I had an idea about that but didn't really want to clutter the
> response to the general idea with it. At least on Linux (I don't know
> if it's the case elsewhere..), creating a POSIX shm ends up creating an
> actual 'file' in /dev/shm/, which yo
Tom Lane wrote:
Yeah, I would be far more interested in this patch if it avoided needing
SysV shmem at all. The problem is to find an adequate substitute for
the nattch-based interlock against live children of a dead postmaster.
(confused) Why can't you use mmap of /dev/zero and inherit the
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Yeah, I would be far more interested in this patch if it avoided needing
> SysV shmem at all. The problem is to find an adequate substitute for
> the nattch-based interlock against live children of a dead postmaster.
Right, I had an idea about that but didn
Stephen Frost <[EMAIL PROTECTED]> writes:
> Finding a way for POSIX shm to do what we need, including Tom's
> concerns, without depending on SvsV shm as a crutch work around, would
> make this change much more reasonable and could be justified as moving
> to a well defined POSIX standard, and means
Chris, et al,
(commit-fest consensus discussion)
* Chris Marcellino wrote:
> In case you haven't had enough, here is another version of the code
> to make Postgres use POSIX shared memory. Along with the issues that
> have already been addressed, this version ensures that orphaned
> backends