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