Re: pg_locks needs a facelift

From: Jim C. Nasby
Subject: Re: pg_locks needs a facelift
Date: ,
Msg-id: 20050502204723.GV47820@decibel.org
(view: Whole thread, Raw)
In response to: Re: pg_locks needs a facelift  ("Merlin Moncure")
List: pgsql-hackers

Tree view

pg_locks needs a facelift  (Tom Lane, )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )
  Re: pg_locks needs a facelift  (Tom Lane, )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )
  Re: pg_locks needs a facelift  (Alvaro Herrera, )
  Re: pg_locks needs a facelift  (Tom Lane, )
   Re: pg_locks needs a facelift  ("Jim C. Nasby", )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )
  Re: pg_locks needs a facelift  (Tom Lane, )
  Re: pg_locks needs a facelift  ("Jim C. Nasby", )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )
  Re: pg_locks needs a facelift  (Alvaro Herrera, )
  Re: pg_locks needs a facelift  (Tom Lane, )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )
  Re: pg_locks needs a facelift  ("Jim C. Nasby", )
   Re: pg_locks needs a facelift  (Tom Lane, )
    Re: pg_locks needs a facelift  ("Jim C. Nasby", )
 Re: pg_locks needs a facelift  ("Merlin Moncure", )

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! www.distributed.net 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:

From: "Joshua D. Drake"
Date:
Subject: Re: Heads up: impending 8.0, 7.4, 7.3 releases
From: Robert Treat
Date:
Subject: Re: [pgsql-advocacy] Decision Process WAS: Increased company involvement