Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
Date
Msg-id 20141012003357.GS21267@momjian.us
Whole thread Raw
In response to Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
List pgsql-hackers
On Tue, Aug 12, 2014 at 07:08:06PM -0400, Robert Haas wrote:
> On Tue, Aug 12, 2014 at 12:59 PM, Andres Freund <andres@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?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [REVIEW] pg_last_xact_insert_timestamp
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_dump refactor patch to remove global variables