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. 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers