Skip site navigation (1) Skip section navigation (2)

Re: POSIX shared memory support

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Chris Marcellino <cmarcellino(at)apple(dot)com>
Subject: Re: POSIX shared memory support
Date: 2008-04-02 15:50:27
Message-ID: 200804021550.m32FoRk18898@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
The original patch author:

        Chris Marcellino <cmarcellino(at)apple(dot)com>

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 --- the bottom line is that there isn't much
support for the patch.  Magnus was able to do the POSIX usage without
relying on shared memory, but I just talked to him via IM and he said it
used a Win32-specific feature that isn't portable to Unix.

I am holding this patch for the next commit fest in hopes you can adjust
it, but if not the patch will be rejected at that time.

---------------------------------------------------------------------------

Stephen Frost wrote:
-- Start of PGP signed section.
> 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 are not in the database when restarting Postgres by using a  
> > single 1 byte SysV segment to see who is attached to the segment  
> > using shmctl/IPC_STAT/nattach.
> 
> This really feels like a deal-breaker to me.  My first reaction to this
> patch, honestly, is that it's being justified for all the wrong reasons.
> Changing to POSIX shm seems like a reasonable goal in general, provided
> it can do what we need, but doing it to work around silly defaults
> doesn't really work for me.  If the real issue you have is with the SysV
> limits then I'd suggest you bring that up with the kernel/distribution
> folks to get them to use something more sane.
> 
> Looking around a bit, it looks like it's already being addressed in some
> places, for example Solaris 10 apparently uses 1/4th of memory, while
> Centos 5 uses 4GB.  Suse also uses a larger default, from what I
> understand.  Supporting this effort to get it raised on various
> platforms and distributions seems like a much better approach.
> 
> Additionally, it strikes me that there *is* a limit on POSIX shared
> memory too, generally half of ram on the systems I've looked at, but
> there's no guarentee that'll always be the default or that half of ram
> will always be enough for us.  So, even with this change, the problem
> isn't completely 'solved'.
> 
> 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 we may be able to support
> platforms which either are new and don't implement SysV but just POSIX,
> or cases where SysV is being actively depreceated.  Neither of which is
> possible if we're stuck with using it in some cases.
> 
> 	Thanks,
> 
> 		Stephen
-- End of PGP section, PGP failed!

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-04-02 15:51:33
Subject: Re: varadic patch
Previous:From: Tom LaneDate: 2008-04-02 15:50:00
Subject: Re: varadic patch

pgsql-patches by date

Next:From: Brendan JurdDate: 2008-04-02 15:52:23
Subject: Re: Consistent \d commands in psql
Previous:From: Tom LaneDate: 2008-04-02 15:40:19
Subject: Re: Consistent \d commands in psql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group