Re: pg_locks needs a facelift

Tom Lane wrote:
> > 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.
>
> Well, sure, but that's what "SELECT ... WHERE" is for ;-)

yeah, I misread your earlier post...being able to filter on lock type
(or not) is an ideal solution. So, pg_locks it is.

I'd also like to make one more comment:
> This still leaves us with the issue of what to do with user locks.
> I am inclined to display them as if they were OBJECT locks, ie, fill
> the database, classid, objid, and objsubid columns. An alternative
> that would also expose all the info is to display them as if they
> were TUPLE locks. Or we could add still more columns, but I'm not
> real enthused about that idea.

I don't like the idea of listing user locks with 'tuple' locks for no
other reason than this might confuse what user locks are. Even though
they will be used as tuple locks 99% of the time, user locks are only
loosely coupled with tuples in part because there is no sytem generated
column which is persistent and > 32 bits. IMO, this is a problem with
the current user lock module...it encourages locking over oid which is a
bad practice. A properly implemented user lock system would likely
maintain a global sequence shared by all lockable objects, tuple or
otherwise.

Listing them as object locks seems ok.

Merlin