On Sun, Nov 14, 2010 at 11:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
One of the things that would be really nice to be able to do is resize
our shm after startup, in response to changes in configuration
parameters. That's not so easy to make work, of course, but I feel
like this might be going in the right direction, since POSIX shms can
be resized using ftruncate().
> 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.
I've never had a lot of luck making filesystem locks work reliably,
but I don't discount the possibility that I was doing it wrong.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company