On Sun, Nov 14, 2010 at 11:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Martijn van Oosterhout <klep...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers