Prev: HS - odd process listing
Next: Protecting against case where shmget says EINVAL instead of EEXIST
From: Tom Lane on 1 May 2010 12:01
The thread here
http://archives.postgresql.org/pgsql-admin/2010-04/msg00358.php
shows that current OS X contains the same issue that was complained of
a year or so ago with respect to NetBSD. Namely, that if shmget finds
an existing shared memory segment that is smaller than the current
request, it will return EINVAL, rather than EEXIST which is what
InternalIpcMemoryCreate is expecting to get for a collision. This
leads to an unnecessary startup failure with a completely misleading
error message. It's easy to reproduce on a Mac:

1. kill -9 an existing postmaster.
2. edit postgresql.conf to increase max_connections by 1.
3. try to start postmaster.

You get

FATAL: could not create shared memory segment: Invalid argument
DETAIL: Failed system call was shmget(key=5432001, size=29622272, 03600).
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 29622272 bytes), reduce PostgreSQL's shared_buffers parameter (currently 3072) and/or its max_connections parameter (currently 105).
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.

In the previous go-round, the misleading errno was reported to NetBSD
as a kernel bug. I see from their CVS that they did fix it: see 1.113 in
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sysv_shm.c

But what now seems clear to me is that this behavior probably exists
in *every* BSD-derived kernel. It's unlikely that we can get them all
fixed, especially in view of the POSIX standard's wording saying that a
kernel's order of error checking is not guaranteed. It'd be smarter for
us to install a workaround.

The workaround I'm thinking of is, when we see EINVAL, to try another
shmget with the same key and flags, and size zero. If this results in
EEXIST or EACCES then handle it as a collision. Otherwise clean up the
new segment (if we managed to make one, which is unlikely) and report
the original EINVAL. This depends on the knowledge that these kernels
don't check the size against shmmin/shmmax in the code path where
there's an existing segment, so we will not get an EINVAL on the basis
of the size and will instead see an errno that reflects the collision,
if there is one.

Comments?

regards, tom lane

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

 | 
Pages: 1
Prev: HS - odd process listing
Next: Protecting against case where shmget says EINVAL instead of EEXIST