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