On Thu, Jun 12, 2014 at 5:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > With regard to Andres' proposal, I'm not that keen on setting
>> > dynamic_shared_memory_type='none' by default.
>
> Note that I'm not proposing to disable the whole thing. Just that a
> unset dynamic_shared_memory_type doesn't configure dsm. Initdb would
> still configure it after probing.
OK, I misunderstood your position; thanks for clarifying. I think
that would be OK with me. To some degree, I think that the test setup
is broken by design: while we try to maintain backward-compatibility
for postgresql.conf files, there's never been any guarantee that an
old postgresql.conf file will work on a newer server. For example, a
whole lot of pre-8.4 users probably had max_fsm_pages and
max_fsm_relations configured, and with 8.4, those settings went away.
Fixing that kind of thing is an essential part of the upgrade process.
That having been said, in this particular case, we can probably ease
the pain without much downside by doing as you suggest. The only
thing I'm worried about is that people will discover much later that
they don't have working dynamic shared memory, and be unhappy about
that. Sometimes it's better to complain loudly at the beginning than
to leave buried problems for later. But I'll defer to the majority on
what to do in his instance.
>> To me, the following should be done:
>> * Make initdb determine the best shm type for this platform and write
>> it into postgresql.conf as it does now.
>> * If no dynamic_shared_memory_type is found in the config, default to
>> "none".
>> * Modify the three identical error messages concerned about shm
>> segments to include the shm type instead of always just saying
>> "FATAL: could not open shared memory segment"
>> * Add a HINT to the POSIX error message:
>> "HINT: This might indicate that /dev/shm is not mounted, or its
>> permissions do not allow the database user to create files there"
>
> Sounds like a sane plan to me.
+1 to the rest of this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company