Re: pg_locks needs a facelift - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_locks needs a facelift
Date
Msg-id 18751.1115048277@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_locks needs a facelift  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-hackers
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> 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.

Well, sure, but that's what "SELECT ... WHERE" is for ;-)

> 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.

The proposal I made was to display all fields of a USER lock as either
OID or int2, so you can certainly cast the OIDs to int4 if you want to
do some kind of arithmetic on them.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: SPI bug.
Next
From: Heikki Linnakangas
Date:
Subject: Re: Feature freeze date for 8.1