Re: pg_locks needs a facelift

From: Merlin Moncure
Subject: Re: pg_locks needs a facelift
Date: ,
Msg-id: 6EE64EF3AB31D5448D0007DD34EEB3415C2723@Herge.rcsinc.local
(view: Whole thread, Raw)
In response to: pg_locks needs a facelift  (Tom Lane)
Responses: Re: pg_locks needs a facelift  ("Jim C. Nasby")
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:
> 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.

Well, actually, as currently implemented the userlock module provides 48
bits of lock space but none of the bits are reserved for
anything...interface functions which assign the lower 32 bits to oid are
provided as a convenience.  IIRC userlocks were first implemented in
1998 when the oid played a larger role, it is now quite rightly
deprecated and my intention is to remove it from the userlock module.

The new userlocks should be able to take advantage of refinements in the
locktag structure and provide a full 64 bits to resolve the lock at the
least.  64 bits is the magic number because it now works quite nicely
with sequences.  Could you be more specific about how a string based
user lock system would be implemented?


Merlin



pgsql-hackers by date:

From: "Marc G. Fournier"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
From: "Joshua D. Drake"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement