Your message dated Sat, 12 Jan 2013 22:31:13 +0100
with message-id <[email protected]>
and subject line Re: Bug#642133: [postgresql-9.1] After upgrading from 9.0 to
9.1 postgres fails to start: FATAL: could not create shared memory segment:
Invalid argument
has caused the Debian Bug report #642133,
regarding [postgresql-9.1] After upgrading from 9.0 to 9.1 postgres fails to
start: FATAL: could not create shared memory segment: Invalid argument
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
642133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642133
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: postgresql-9.1
Version: 9.1~rc1-3
Severity: important
--- Please enter the report below this line. ---
I was running postgres 9.0 and I decided to upgrade to 9.1.
I installed the new 9.1 package, and then ran the following commands as
postgres user:
$ pg_dropcluster 9.1 main --stop
$ pg_upgradecluster 9.0 main
At which point it converted all the databases, unfortunately I lost the
output but I remember the conversion was successful.
After the conversion however postgres 9.1 failed to start, the full
error is:
$ /etc/init.d/postgresql start
Starting PostgreSQL 9.1 database server: mainThe PostgreSQL server
failed to start. Please check the log output: 2011-09-20 01:39:00 SGT
FATAL: could not create shared memory segment: Invalid argument
2011-09-20 01:39:00 SGT DETAIL: Failed system call was
shmget(key=5432001, size=34922496, 03600). 2011-09-20 01:39:00 SGT HINT:
This error usually means that PostgreSQL's request for a shared memory
segment exceeded your kernel's SHMMAX parameter. You can either reduce
the request size or reconfigure the kernel with larger SHMMAX. To reduce
the request size (currently 34922496 bytes), reduce PostgreSQL's shared
memory usage, perhaps by reducing shared_buffers or max_connections. If
the request size is already small, it's possible that it is less than
your kernel's SHMMIN parameter, in which case raising the request size
or reconfiguring SHMMIN is called for. The PostgreSQL documentation
contains more information about shared memory configuration. ... failed!
failed!
I attach the full log in /var/log/postgresql/postgresql-9.1-main.log
Regards,
Paolo.
--- System information. ---
Architecture: i386
Kernel: Linux 3.0.0-1-686-pae
Debian Release: wheezy/sid
500 testing www.debian-multimedia.org
500 testing security.debian.org
500 testing ftp.us.debian.org
500 testing deb.opera.com
500 stable dl.google.com
500 squeeze debian.fusionforge.org
50 experimental ftp.us.debian.org
100 unstable ftp.us.debian.org
--- Package information. ---
Depends (Version) | Installed
=============================================-+-====================
libc6 (>= 2.11) | 2.13-18
libcomerr2 (>= 1.01) | 1.42~WIP-2011-07-02-1
libgssapi-krb5-2 (>= 1.8+dfsg) | 1.9.1+dfsg-1
libkrb5-3 (>= 1.6.dfsg.2) | 1.9.1+dfsg-1
libldap-2.4-2 (>= 2.4.7) | 2.4.25-3
libpam0g (>= 0.99.7.1) | 1.1.3-2
libpq5 (>= 9.1~beta1) | 9.1~rc1-3
libssl1.0.0 (>= 1.0.0) | 1.0.0d-3
libxml2 (>= 2.7.4) | 2.7.8.dfsg-4
zlib1g (>= 1:1.2.3.3.dfsg) | 1:1.2.3.4.dfsg-3
postgresql-client-9.1 | 9.1~rc1-3
postgresql-common (>= 115~) | 121
tzdata | 2011i-2
ssl-cert | 1.0.28
locales | 2.13-18
Package's Recommends field is empty.
Suggests (Version) | Installed
===========================-+-===========
oidentd |
OR ident-server |
locales-all |
--- End Message ---
--- Begin Message ---
Re: Michael Stapelberg 2012-06-25 <[email protected]>
> Interestingly, shmmax was set to 5 MB:
>
> $ sysctl -a | grep shm
> kernel.shmmax = 5922496
> kernel.shmall = 2097152
> kernel.shmmni = 4096
>
> After changing it to 50 MB, starting postgresql worked again. Which is
> strange, because I didn’t change the configuration file and it was
> running fine before this upgrade o_O.
>
> I suspected it has something to do with available memory (which might
> be lower then when I last started postgresql):
Hi,
postgres (or rather initdb) does some auto-probing to find some
shared_buffers value that works. In some cases that means you'll get
some ridiculous low value for shared_buffers buffers. This doesn't
depend on free memory, but only on how large the kernel will let you
allocate sysv shared memory segments. Once configured, postgres will
refuse to start if it cannot allocate the segment.
Anyway, this is not a postgres bug, the admin needs to configure the
kernel such that two clusters can be running at the same time, for the
upgrade process to be useful.
There's nothing wrong with setting really large values for shmmax and
shmall. These are only upper bounds, they do not change anything
except that they let you allocate more memory.
Christoph
--
[email protected] | http://www.df7cb.de/
signature.asc
Description: Digital signature
--- End Message ---
