public inbox for [email protected]  

help / color / mirror / Atom feed

From: Merlin Moncure <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: [HACKERS] pg_locks view and user locks
Date: Mon, 13 Sep 2004 16:12:32 -0400
Message-ID: <[email protected]> (raw)

> Merlin Moncure wrote:
> > Second,
> > Is there a reason why user level locks are completely undocumented?
> > AFAICT, There is no mention of them in anywhere in the docs,
> > particularly 12.4, which describes methods for application managed
> > concurrency.  The availability of cooperative long term locks is
> > (IMO) a really nice feature, particularly for people porting legacy
> > applications which depend on explicit locking (there is some good
> > info in the user lock module which is unfortunately under the GPL).
> 
> That's the whole problem.  I don't think anyone objects to the user
lock
> principle, but as long as it's GPL, we won't support it.  It was
> probably a mistake to accept this module in the first place.  I
believe
> some people have been trying to get the module relicensed, but that
> evidently never happened.

Well, the lock module itself is nothing more than some wrappers for the
system lock manager functions (LockAcquire,etc) in C and wrappers for
those in SQL, plus a makefile and some basic documentation...in other
words almost nothing.

If the 'userlock' module author can't be found or refuses to open his
module, why not simply rewrite it?  It's extremely small.  This also
gives an opportunity to add some missing parts, like resolving a lock to
a pid and better error handling.

In any case, IMHO it is worthwhile to flesh out 12.3, adding user locks
(simply listing as a lock type), 12.4 with usage of above, perhaps with
an example.  Also a mention of userlocks in 43.32 and possibly a new
entry in this section, depending on how they get handled per my
suggestion wrt pg_locks.  Also possibly a note in 16.4.8
(postgresql.conf entry for max_locks_per_transaction) describing the
interaction between this parameter and user locks (aside: is there
any?).  Certain aspects of these changes would of course depend on the
feasibility of moving some of the lock interfaces into the main project.

I'd be willing to have a stab at the above, is it worthwhile?

Merlin

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] pg_locks view and user locks
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox