Re: Shared memory changes in 9.4? - Mailing list pgsql-hackers

[redirecting to -hackers]

Re: Robert Haas 2014-05-28 <CA+TgmoaTcAd48zW3auWzGdHi_V+QwA5HVCTabqgTq=ZLWpysEQ@mail.gmail.com>
> On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda <m.sakrejda@gmail.com> wrote:
> > On Mon, May 26, 2014 at 12:24 AM, Andres Freund <andres@2ndquadrant.com>
> > 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.

Hi,

I've just run into the same problem. I am running the Debian
postgresql-common testsuite, which includes upgrade tests. On
upgrades, the old postgresql.conf is copied to the new server (after
initdb and/or pg_upgrade), and deprecated options are removed/renamed. [*]

In that chroot environment, 9.4 is running fine, except that upgrades
failed because /dev/shm wasn't mounted, and the old 9.3
postgresql.conf doesn't contain dynamic_shared_memory_type = 'sysv'.

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
notallow the database user to create files there"
 

Despite /dev/shm having been around for quite some time, many people
seem to be unaware what POSIX shared memory is, so the HINT is really
needed there. It certainly took me weeks after seeing the error
message the first time till I found the time to dig deeper to the
issure - it should just have been "oh yes, /dev/shm isn't mounted
there, that's why".

Christoph

[*] This might not be the smartest thing to do, but it's a simple
default approach to get the new cluster running with as much user
config from the old config as possible.
-- 
cb@df7cb.de | http://www.df7cb.de/