On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote: > No way to fail is a tall order.
Well, no way to fail due to running out of shared memory in RegisterPredicateLock/RegisterPredicateLockingXid, but that doesn't have quite the same ring to it... > If we don't allocate all the memory up front, does that allow memory > to be dynamically shared between different hash tables in shared > memory? I'm thinking not, but... Not in a useful way. If we only allocate some of the memory up front, then the rest goes into the global shmem pool (actually, that has nothing to do with the hash table per se, just the ShmemSize calculations), and it's up for grabs for any hash table that wants to expand, even beyond its declared maximum capacity. But once it's claimed by a hash table it can't get returned. This doesn't sound like a feature to me. In particular, I'd worry that something that allocates a lot of locks (either of the heavyweight or predicate variety) would fill up the associated hash table, and then we're out of shared memory for the other hash tables -- and have no way to get it back short of restarting the whole system. > Frankly, I think this is an example of how our current shared memory > model is a piece of garbage. Our insistence on using sysv shm, and > only sysv shm, is making it impossible for us to do things that other > products can do easily. My first reaction to this whole discussion > was "who gives a crap about 2MB of shared memory?" and then I said > "oh, right, we do, because it might cause someone who was going to get > 24MB of shared buffers to get 16MB instead, and then performance will > suck even worse than it does already". But of course the person > should really be running with 256MB or more, in all likelihood, and > would be happy to have us do that right out of the box if it didn't > require them to do tap-dance around their kernel settings and reboot. I'm completely with you on this. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
