I thought about this problem a little, and also discussed it with
upstream. Basically, we have four options:

(1) Ignore
    + no hidden magic
    - very inconvenient, package installation does not create default
      cluster sometimes, or the default cluster fails to start on
      system boot

   Best solution for admin control freaks.

(2) Bee shy about initdb's default setting and set it to 3/4 of the available 
memory.
    + no hidden magic
    + upstream compatible solution
    - suboptimal performance by default

(3) Change SHMALL/SHMMAX in postgresql's init script if necessary
    + Always works
    - Unexpected, works behind admin's back.

(4) Set a bigger SHMALL default in the kernel.
    + no hidden magic
    + no guesswork involved in scripts
    + no hidden magic

Upstream recommended to do (4). Quote: "I imagine BTW that it's SHMALL
that's causing you issues.  SHMMAX shouldn't have any effect that varies
depending on what else is using shared memory."

I reassign this to the kernel guys to get their input.

This is still not breaking many boxes, and intrusive to solve either
way, so taking off the Jaunty radar.

** Package changed: postgresql-common (Ubuntu Jaunty) => linux (Ubuntu
Jaunty)

** Changed in: linux (Ubuntu Jaunty)
       Status: Triaged => Won't Fix

** Changed in: linux (Ubuntu Jaunty)
     Assignee: Martin Pitt (pitti) => (unassigned)

-- 
pgsql fails to start due to shared buffer setting greater than kernel allows
https://bugs.launchpad.net/bugs/264336
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to