dynamic shared memory: wherein I am punished for good intentions

Since, as has been previously discussed in this forum on multiple
occasions [citation needed], the default System V shared memory limits
are absurdly low on many systems, the dynamic shared memory patch
defaults to POSIX shared memory, which has often been touted as a
superior alternative [citation needed]. Unfortunately, the buildfarm
isn't entirely happy with this decision. On buildfarm member anole
(HP-UX B.11.31), allocation of dynamic shared memory fails with a
"Permission denied" error, and on smew (Debian GNU/Linux 6.0), it
fails with "Function not implemented", which according to a forum
post[1] I found probably indicates that /dev/shm doesn't mount a tmpfs
on that box.

What shall we do about this? I see a few options.

(1) Define the issue as "not our problem". IOW, as of now, if you
want to use PostgreSQL, you've got to either make POSIX shared memory
work on your machine, or change the GUC that selects the type of
dynamic shared memory used.

(2) Default to using System V shared memory. If people want POSIX
shared memory, let them change the default.

(3) Add a new setting that auto-probes for a type of shared memory
that works. Try POSIX first, then System V. Maybe even fall back to
mmap'd files if neither of those works.

(4) Remove the option to use POSIX shared memory. System V FTW!

After some consideration, I think my vote is for option #2. Option #1
seems too user-hostile, especially for a facility that has no in-core
users yet, though I can imagine we might want to go that way
eventually, especially if we at some point try to dump System V shared
memory altogether, as has been proposed. Option #4 seems sad; we know
that System V shared memory limits are a problem for plenty of people,
so it'd be a shame not to have a way to use the POSIX facilities if
they're available. Option #3 is fine as far as it goes, but it adds a
significant amount of complexity I'd rather not deal with.

Other votes? Other ideas?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] http://forums.justlinux.com/showthread.php?142429-shm_open-problem