On Thu, Aug 20, 2015 at 4:13 PM, David Brownlee <abs@absd.org> wrote:
>> 2) The initdb problem is actually not our fault. It looks like a
>> NetBSD kernel bug when allocating large shared memory blocks on a
>> machine without lots of memory. There's not much initdb can do with a
>> kernel panic...
>
> That should definitely be fixed...
cf
http://mail-index.netbsd.org/port-vax/2015/08/19/msg002524.html
http://comments.gmane.org/gmane.os.netbsd.ports.vax/5773
It's possible it's a simh bug it smells more like a simple overflow to me.
>> BSD still has the problem of kern.maxfiles defaulting
>> to a value low enough that even two connections causes the regression
>> tests to run out of file descriptors. That's documented and it would
>> be a right pain for initdb to detect that case.
>
> Is initdb calling ulimit() to check/set open files? Its probably worth
> it as a sanity check if nothing else.
Yup, we do that.
> I think the VAX default open_max is 128. The 'bigger' ports have a
> default of 1024, and I think they should probably all be updated to
> that, though that is orthogonal to a ulimit() check.
That's the problem. initdb tests how many connections can start up
when writing the default config. But we assume that each process can
use up to the rlimit file descriptors without running into a
system-wide limit. Raising it to 1024 lets me get two processes
running which is how I'm running them currently.
Also I forgot to mention, I also have to raise the stack limit with
ulimit. The default is so small that Postgres calculates the maximum
safe value for its max_stack_depth config is 0.
--
greg
