Re: shared memory release following failed lock acquirement.

> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > In other words, after doing a select user_write_lock_oid(t.oid) from
> > big_table t;
> > It's server restart time.
>
> User locks are not released at transaction failure.  Quitting that
> backend should have got you out of it, however.

Right, my point being, it doesn't.
> > What's really interesting about this is that the pg_locks view
(after
> > the offending disconnects) reports nothing out of the ordinary even
> > though no backends can acquire locks after that point.
>
> User locks are not shown in pg_locks, either.

Well, actually, they are.  The lock tag values are not shown, but they
do show up as mostly blank entries in the view.
> 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, this perhaps explains it.  You are saying then that I am running the
server out of shared memory, not necessarily space in the lock table.  I
jumped to the conclusion that the memory associated with the locks might
not have been getting freed.
> I don't think it's practical to introduce a real shared memory
> allocator, but maybe we could alleviate the worst risks by forcing the
> buffer hash table up to full size immediately at startup.  I'll look
at
> this.

This still doesn't fix the problem (albeit a low priority problem,
currently just a contrib. module) of user locks eating up all the space
in the lock table.  There are a couple of different ways to look at
fixing this.  My first thought is to bump up the error level of an out
of lock table space to 'fatal'.

Merlin