> 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


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

"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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster