On 04/21/2014 11:39 AM, Magnus Hagander wrote:
> On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund <andres@2ndquadrant.com
> <mailto:andres@2ndquadrant.com>> wrote:
>
> On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com
> <mailto:andres@2ndquadrant.com>> writes:
> > > If there are indeed such large regressions on FreeBSD we need
> to treat
> > > them as postgres regressions. It's nicer not to add config
> options for
> > > things that don't need it, but apparently that's not the case
> here.
> >
> > > Imo this means we need to add GUC to control wether anon
> mmap() or sysv
> > > shmem is to be used. In 9.3.
> >
> > I will resist this mightily. One of the main reasons to switch
> to mmap
> > was so we would no longer have to explain about SysV shm
> configuration.
>
> It's still explained in the docs and one of the dynshm implementations
> is based on sysv shmem. So I don't see this as a convincing reason.
>
> Regressing installed OSs by 15-20% just to save a couple of lines of
> docs and code seems rather unconvincing to me.
>
>
> There's also the fact that even if it's changed in FreeBSD, that might
> be somethign that takes years to trickle out to whatever stable
> release people are actually using.
>
> But do we really want a *guc* for it though? Isn't it enough (and in
> fact better) with a configure switch to pick the implementation when
> multiple are available, that could then be set by default for example
> by the freebsd ports build? That's a lot less "overhead" to keep
> dragging around...
>
>
That seems to make more sense. I can't imagine why this would be a
runtime parameter as opposed to build time.
cheers
andrew
