Re: shared memory release following failed lock acquirement.

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: shared memory release following failed lock acquirement.
Date: 2004-09-28 19:45:47
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A74D4@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2004-09-28 19:57:46 Re: type unknown - how important is it?
Previous Message Tom Lane 2004-09-28 19:02:02 Re: shared memory release following failed lock acquirement.