Search Postgresql Archives

Re: Shared memory changes in 9.4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda <m.sakrejda@xxxxxxxxx> wrote:
> On Mon, May 26, 2014 at 12:24 AM, Andres Freund <andres@xxxxxxxxxxxxxxx>
> wrote:
>>
>> Any chance you're using a 9.3 configuration file instead of the one
>> generated by initdb?
>> dynamic_shared_memory_type defaults to 'posix' if not specified in the
>> config file (on platforms supporting it). If initdb detects that 'posix'
>> can't be used it'll emit a different value. If you're copying the config
>> from 9.3 and your environment doesn't support posix shm that'll cause
>> the above error.
>> I still think dynamic_shared_memory_type should default to 'none'
>> because of such problems
>
> It works with 'none' and 'sysv'--I think the issue is that technically our
> environment does support 'posix', but '/dev/shm' is indeed not mounted in
> the LXC container, leading to a discrepancy between what initdb decides and
> what's actually possible. Thanks for your help.

I think it would be good to understand why initdb isn't getting this
right.  Did you run initdb outside the LXC container, where /dev/shm
would have worked, but then run postgres inside the LXC container,
where /dev/shm does not work?  I ask because initdb is supposed to be
doing the same thing that postgres does, so it really ought to come to
the same conclusion about what will and won't work.

With regard to Andres' proposal, I'm not that keen on setting
dynamic_shared_memory_type='none' by default.  Would we leave it that
way until we get in-core users of the facility, and then change it?  I
guess that'd be OK, but frankly if enabling dynamic_shared_memory_type
by default is causing us many problems, then we'd better reconsider
the design of the facility now, before we start adding more
dependencies on it.  We've already fixed a bunch of DSM-related issues
as a result of the fact that the default *isn't* none, and I dunno how
many of those we would have found if the default had been none.  I
tend to think DSM is an important facility that we're going to be
wanting to build on in future releases, so I'm keen to have it
available by default so that we can iron out any kinks before we get
too far down that path.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux