Re: userlock changes for 8.1/8.2 - Mailing list pgsql-hackers

Tom Lane wrote:
> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > However, it would be nice to have system generated unique tuple
> > identifier.  There isn't one currently that would fit in the
userlock
> > restriction of 48 bits.
>
> Sure there is: the ctid of a row in an agreed-on table works fine.
> The reason it's system-wide unique is that user_locks.c forcibly
> includes your database OID in the lock tag.
>
> It would be reasonable to allow user control of the lock's relId field
> and maybe even dbId field, but that just takes an expansion of the API
> for user_locks.c.  There's no need to put overhead on the rest of
> Postgres for this.

Ok, you answered my next question.  Part of my confusion here is the
comments in front of LockAcquire() which explains how userlocks are
supposed to be mapped to the lock tag.  In the case of userlocks, the
locktag is basically a hash key, right?  so we can recover the other
fields and have enough room to play with to generate a 'real'
identifier, but...

ctid is useless for user locks because an update from a non-cooperating
client will change it unless the locks become non-cooperative, and now
we are talking about classic row level locks...not worth considering
IMO.  IOW, a 'user lock' candidate identifier generated by the database
must be both unique and persistent for the lifetime of the lock.

Without using ctid (and don't want to use oid), there is nothing that
can be pulled from the tuple that persistently identifies it until the
oid is extended to 64 bits or beyond which doesn't seem likely at this
point, so we are back to the classic approach of using an application
managed sequence.


So the only changes to the current sources in the core project outside
of documentation are:

1. update comments to LockAcuire() in lock.c
2. (proposing) new system type that covers the maximum bitspace allowed
inside locktag structure, and add a union here to reduce confusion
(encompassing offsetnum but not lockmethodid).
3. pg_lock_status(): I prefer to alter this function to simply return
the follwing:

lockdatum     locktype  <-- bits of locktag structure except for type
pid        integer
locktype    integer
granted    boolean

'lock type' mentioned above as a single datum per lock.  This can be
parsed at the view stage for different types of locks.
So,
select * from pg_locks <--pulls from pg_lock_status filtering on default
lock method
select * from pg_user_locks <--pulls from pg_lock_status filtering on
user lock method

IMO, this is a good setup because it clearly defines the different
types.  This will become even more important if and when more lock types
get added to this system...shared locks for example.  To make this work,
though at the very least a built in cast for int->xid would have to be
added, since there are no casts to or from xid currently.  If doesn't
fly, of course an alternative is to just add more functions to
lockfuncs.c for various locktypes (as well as new lock views).

And finally,
4. a new function in lock.c allowing a lock owned by another process to
be killed.

Merlin