On Tue, May 27, 2014 at 8:23 PM, Robert Haas <robertmhaas@xxxxxxxxx> 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 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
> ....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.
