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