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