Re: pg_locks needs a facelift

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

> >  A properly implemented user lock system would likely
> > maintain a global sequence shared by all lockable objects, tuple or
> > otherwise.
>
> That'd just be equivalent to require that user tables are created WITH
> OIDS, only the counter wouldn't be shared with system tables ... how
is
> that any better?

Well, oid is 32 bit and not guaranteed to be unique...therefore useless.
However by properly defined, I meant by the application.  The server is
agnostic about user locks, a.k.a. 'application defined locks'.

Merlin



pgsql-hackers by date:

From: "Jim C. Nasby"
Date:
Subject: Re: pg_locks needs a facelift
From: Andrew Dunstan
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement