Martijn van Oosterhout <kleptog@svana.org> writes:
> The only real solution seems to me to be to keep a small SysV shared
> memory segment for the locking and allocate the rest of the shared
> memory some other way.
Yeah, that's been discussed. It throws all the portability gains out
the window. It might get you out from under the need to readjust a
machine's SHMMAX setting before you can use a large amount of shared
memory, but it's not clear that's enough of a win to be worth the
trouble.
The other direction that we could possibly go is to find some other way
entirely of interlocking access to the data directory. If for example
we could rely on a file lock held by the postmaster and all backends,
we could check that instead of having to rely on a shmem behavior.
The killer objection to that so far is that file locking is unreliable
in some environments, particularly NFS. But it'd have some advantages
too --- in particular, in the NFS context, the fact that the lock is
visible to would-be postmasters on different machines might be thought
a huge safety improvement over what we do now.
regards, tom lane