Re: dynamic shared memory: wherein I am punished for good intentions

On 10/10/2013 12:13 PM, Robert Haas wrote:
> 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?
>

5) test and set it in initdb.

cheers

andrew