Re: pg_locks needs a facelift

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

> In the earlier thread there was talk of separate views for system
> and user locks, but on reflection I think that's the wrong approach;
> principally because it will be impossible to get exactly-simultaneous
> snapshots of the system and user lock states if there are two views
> involved.  And that's something you tend to want when studying lock
> behavior ;-).  So I think we have to maintain the current arrangement
> of one view, and add enough columns to it to handle all the
> requirements.

This seems perfectly ok...as long as there is 1:1 correspondence between
locktag and lock for all present and future types of locks.  I'd like to
point out though that when querying for user locks it's kind of nice not
to wade through transaction locks, etc.

One nice things about the generic types (int4) is that they can be
easily casted...if a column is displaying an xid that is not really an
xid (user lock block offset), this can be annoying if you want to do
some post query processing on the field, like bit shift it back into a
64 bit variable...especially since a dump/restore will drop all casts
between two system provided columns.

What about having a view with all the generic columns and one
specialized view (pg_locks) for backwards compatibility?

Merlin




pgsql-hackers by date:

From: "Joshua D. Drake"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
From: Bruce Momjian
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement