Skip site navigation (1) Skip section navigation (2)

shared memory release following failed lock acquirement.

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: shared memory release following failed lock acquirement.
Date: 2004-09-28 18:52:24
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A74D3@Herge.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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.



pgsql-hackers by date

Next:From: Tom LaneDate: 2004-09-28 19:02:02
Subject: Re: shared memory release following failed lock acquirement.
Previous:From: Shachar ShemeshDate: 2004-09-28 18:27:21
Subject: type unknown - how important is it?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group