Re: shared memory release following failed lock acquirement.

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