Re: [GENERAL] Shared memory changes in 9.4?

2014-05-28 Thread Maciek Sakrejda
On Mon, May 26, 2014 at 12:24 AM, Andres Freund and...@2ndquadrant.comwrote:

 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.

Thanks,
Maciek


Re: [GENERAL] Shared memory changes in 9.4?

2014-05-27 Thread Robert Haas
On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda m.sakre...@gmail.com wrote:
 On Mon, May 26, 2014 at 12:24 AM, Andres Freund and...@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.

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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Shared memory changes in 9.4?

2014-05-27 Thread Maciek Sakrejda
On Tue, May 27, 2014 at 8:23 PM, Robert Haas robertmh...@gmail.com wrote:

 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.

You're absolutely right--I thought initdb was containerized as well, but
I looked at our code and this is exactly what's happening.

 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.

For what it's worth, +1. I'm not sure whether or not we had a good reason
for
doing initdb outside the container, but it's definitely an aberrant
configuration,
and should not be taken as evidence that the current default is a problem.


Re: [GENERAL] Shared memory changes in 9.4?

2014-05-26 Thread Andres Freund
Hi,

On 2014-05-25 12:26:20 -0700, Maciek Sakrejda wrote:
 I've been trying to take the 9.4 beta for a spin, but seem to have run into
 a shared memory issue on startup:
 
 FATAL: could not open shared memory segment /PostgreSQL.1804289383:
 Permission denied
 
 We're running Postgres inside LXC, which I suspect is causing problems
 here, but 9.0 through 9.3 run just fine in the same configuration.

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.

 Any idea
 what may have changed? I suspect the solution here is tweaking some LXC
 setting, but I was hoping someone can point me in the right direction.

It sounds like you're not allowing posix shared memory. Possibly just by
not mounting /dev/shm.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] Shared memory changes in 9.4?

2014-05-25 Thread Maciek Sakrejda
Hi,

I've been trying to take the 9.4 beta for a spin, but seem to have run into
a shared memory issue on startup:

FATAL: could not open shared memory segment /PostgreSQL.1804289383:
Permission denied

We're running Postgres inside LXC, which I suspect is causing problems
here, but 9.0 through 9.3 run just fine in the same configuration. Any idea
what may have changed? I suspect the solution here is tweaking some LXC
setting, but I was hoping someone can point me in the right direction.

Thanks,
Maciek Sakrejda
Heroku Postgres


Re: [GENERAL] Shared memory changes in 9.4?

2014-05-25 Thread Tom Lane
Maciek Sakrejda m.sakre...@gmail.com writes:
 I've been trying to take the 9.4 beta for a spin, but seem to have run into
 a shared memory issue on startup:

 FATAL: could not open shared memory segment /PostgreSQL.1804289383:
 Permission denied

 We're running Postgres inside LXC, which I suspect is causing problems
 here, but 9.0 through 9.3 run just fine in the same configuration. Any idea
 what may have changed? I suspect the solution here is tweaking some LXC
 setting, but I was hoping someone can point me in the right direction.

This message is coming out of the new dynamic shared memory code.
I'm not real sure why that's being invoked at startup; perhaps Robert Haas
can elucidate.  Anyway the short answer is that this sounds like a
portability hazard in the new code in src/backend/storage/ipc/dsm_impl.c.
Perhaps you can look into that and identify what's up.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general