Re: pg_locks needs a facelift - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: pg_locks needs a facelift
Whole thread Raw
In response to Re: pg_locks needs a facelift  ("Merlin Moncure")
List pgsql-hackers
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > "Merlin Moncure" <> writes:
> > Fair enough, although I think that at least one major application of
> > user locks would be equivalent to tuple locks.  Somebody was asking
> > for named user locks in the previous thread, and the easiest way to
> > get that is to make a table containing just lock names, and then lock
> > on the CTIDs of that table.  Since there would be no reason to allow
> > UPDATE or DELETE in such a table, the putative instability of CTID
> > doesn't really matter.
> This is fine, but relying on structures outside of shared memory is a
> fairly hefty price.  User locks are very fast and tight and incur zero
> maintenance overhead...with a table you have to consider vacuuming
> strategies + possible reindex for the unique constraint...bleh.  If the
> lock table was not synced and auto-vacuumed, then maybe it could work.
> I also wonder if there would be a race condition if someone tried to
> acquire ctid based named lock at the same time a user lock with the same
> value, unless ctid locks were maintained in a separate hash table.

Well, there's nothing that says you have to actually refer to locks by
name. When I proposed this what I proposed is that the userlock module
provide a dedicated means to map a lock name to a lock number, and
reserve one of the 'lock spaces' (the 16 bit number) for this use, just
as one of them is currently reserved for locks based on OID. But I also
can't think of any reason why lock names need to be persistent, so I
imagine you could store a list of lock names in shared memory with no
backing storage.
Jim C. Nasby, Database Consultant                
Give your computer some brain candy! Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

pgsql-hackers by date:

Subject: Re: Feature freeze date for 8.1
From: Andrew Dunstan
Subject: Re: [pgsql-advocacy] Increased company involvement