tgl wrote: > There is a secondary issue here, which is that we don't have provision > to recycle hash table entries back into the general shared memory pool > (mainly because there *is* no "shared memory pool", only never-yet- > allocated space). So when you do release these locks, the freed space > only goes back to the lock hash table's freelist. That means there > won't be any space for expansion of the buffer hash table, nor any other > shared data structures. This could lead to problems if you hadn't been > running the server long enough to expand the buffer table to full size.
Ok, I confirmed that I'm running the server out of shared memory space, not necessarily the lock table. My server settings were: max_connections: 100 shred bufs: 8192 buffers max_locks: 64 (stock). According to postgresql.conf, using these settings the lock table eats 64*260*100 bytes = < 2M. Well, if it's running my server out of shared memory, it's eating much, much more shmem than previously thought. Also, I was able to acquire around 10k locks before the server borked. This is obviously a lot more than than 64*100. However, I set the max_locks down to 10 and this did affect how many locks could be acquired (and in this case, a server restart was not required). Doubling shared buffers to 16k bumped my limit to over 20k locks, but less than 25k. As I see it, this means the user-locks (and perhaps all locks...?) eat around ~ 6k bytes memory each. This is not really a big deal, 10k locks is way more than a lock heavy application would be expected to use. I'll look into this a bit more... Merlin ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend