Re: Ding-dong, contrib is dead ...

On 9/5/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > It's a pity we didn't have Abhijit's patch 6 weeks ago.
>
> Well, now that we have it, the question is whether we want to do
> anything with it.  One problem is it lacks documentation.

yes, userlocks have to be documented, in particular the dangers of
lock exhaustion.  also a tie-in to the recently upgraded pg_locks view
would be nice.

> However, as I said, I'd really rather choose a new API altogether.  The
> main thing that seems to be lacking is a way to wait for a lock, rather
> than having only the equivalent of ConditionalLockAcquire.  Also I don't
> much like exposing a LOCKMODE directly to user code --- to use
> user_lock() or user_unlock() you have to put magic numbers into your SQL
> code and hope nobody reassigns the C enum values in future releases.
> I'd be inclined to just expose the notions of "share" and "exclusive"
> lock and make these separate functions instead of magic numbers.

I agree 100%.

> And then there's the question of what to expose in the way of lock
> identifier options.  What we've got now is "two int4's or an OID"
> which seems a bit random, not to mention that the key space overlaps
> in an undocumented fashion.  Possibly we could offer OID, int8, or
> two int4s, and modify the code to set locktag_field4 to distinguish
> these cases so that the key spaces are independent.

right, this is some legacy cruft, in fact I raised this to your
attention which was perhaps part of the inspiration to upgrade
pg_locks.

> I have no opinions about function names, except that I'd suggest
> choosing names based around "advisory lock" instead of "user lock".
> Advisory locks are a standard concept and so that terminology
> already tells people something ...

Agreement here also.

As to the point of userlocks being in core, they are in fact already
in core, and have been several years, the name 'userlock' having been
taken from the in source documentation.  The userlock contrib module
is nothing besides some wrappers for exisiting functions built into
the backend.  Removing userlock from contrib just removes a convenient
mechanism to use them.

I also agree with Andrew that pgfoundry is not a appropriate place for
userlocks.  They should be properly documented with a cleaned up api.
I have no objection from them being removed from contrib in the short
term due to the gpl issue, although I am not sure how you can
copyright a function wrapper.

merlin