On 2014-10-11 20:33:57 -0400, Bruce Momjian wrote:
> On Tue, Aug 12, 2014 at 07:08:06PM -0400, Robert Haas wrote:
> > On Tue, Aug 12, 2014 at 12:59 PM, Andres Freund <and...@2ndquadrant.com> 
> > wrote:
> > > On 2014-08-12 09:42:30 -0700, Sean Chittenden wrote:
> > >> One of the patches that I've been sitting on and am derelict in punting
> > >> upstream is the attached mmap(2) flags patch for the BSDs. Is there any
> > >> chance this can be squeezed in to the PostreSQL 9.4 release?
> > >>
> > >> The patch is trivial in size and is used to add one flag to mmap(2) 
> > >> calls in
> > >> dsm_impl.c.  Alan Cox (FreeBSD alc, not Linux) and I went back and forth
> > >> regarding PostgreSQL's use of mmap(2) and determined that the following 
> > >> is
> > >> correct and will prevent a likely performance regression in PostgreSQL 
> > >> 9.4.
> > >> In PostgreSQL 9.3, all mmap(2) calls were called with the flags MAP_ANON 
> > >> |
> > >> MAP_SHARED, whereas in PostgreSQL 9.4 this is not the case.
> > >
> > > The performancewise important call to mmap will still use that set of
> > > flags, no? That's the one backing shared_buffers.
> > >
> > > The mmap backend for *dynamic* shared memory (aka dsm) is *NOT* supposed
> > > to be used on common platforms. Both posix and sysv shared memory will
> > > be used before falling back to the mmap() backend.
> > 
> > Hmm, yeah.  This might still be a good thing to do (because what do we
> > lose?) but it shouldn't really be an issue in practice.
> 
> Is there a reason this was not applied?

IIRC, as pointed out above, it's primarily based on a misunderstanding
about when mmap is used for in dsm. I.e. that it's essentially just a
fallback/toy implementation and that posix or sysv should rather be
used.

Greetings,

Andres Freund

-- 
 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to