Tom,

I noticed your recent corrections to lock.c regarding the releasing of
locks in an out of shared memory condition.  This may or may not be
relevant, but when I purposefully use up all the lock space with user
locks, the server runs out of shared memory and stays out until it is
restarted (not when the backend shuts down as it is supposed to).

In other words, after doing a select user_write_lock_oid(t.oid) from
big_table t;

It's server restart time.

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.

Merlin




Tue, 28 Sep 2004 14:52:24 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
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.

> 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.

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.

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.

			regards, tom lane

Tue, 28 Sep 2004 15:02:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: shared memory release following failed lock acquirement. 