Subject: pg_locks view and user locks

From: "Merlin Moncure" <[email-masked]>
Date: Mon, 13 Sep 2004 13:34:05 -0400

I've been knocking around a bit with user level locks and I have a few
suggestions/questions:

First, the pg_locks view lists user level locks but doesn't really say
much about them.  For example, for traditional locks we get the xid but
for user locks we don't really get anything useful.  I looked in
lockfuncs.c and didn't see that there would be any real penalty to
displaying the offset/block of the user lock, and returning it in
request from pg_locks.  Is this view frequently queried by system
processes? 

Why would we want to do this?  Well it makes resolving a user lock to a
specific pid easier...admittedly of dubious value but helpful to
me...although if this doesn't fly I can always create an alternate view
which serves my purpose (and perhaps add a high level function to the
/contrib userlock module).

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

Not complaining or looking for help, just curious why they seemed to
have slipped through the cracks.

Merlin

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 13 Sep 2004 21:36:19 +0200

Merlin Moncure wrote:
> 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.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---

From: Alvaro Herrera <[email-masked]>
Date: Mon, 13 Sep 2004 16:02:25 -0400

On Mon, Sep 13, 2004 at 01:34:05PM -0400, Merlin Moncure wrote:

> request from pg_locks.

ISTM it would be better to have pg_locks show only system locks, and
another view, say pg_userlocks, to show user locks.  This would allow to
show different data; for example, the PID of the process involved.
What's more, user locks and system locks never conflict, so it seems
wrong to show them together.

Another option would be to add another column to pg_locks to say what
lockmethod (1 for system, 2 for user) is used in each lock.

Maybe we want to separate locks even more, and use one table to show
xact locks, another to show table locks, and yet another to show user
locks.  But maybe this is a bad idea right from the start.

> Is this view frequently queried by system processes? 

I don't think there is a lot of server-side stuff (aside from possible
UDFs) that use pg_locks directly.  It's there only for user convenience.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Someone said that it is at least an order of magnitude more work to do
production software than a prototype. I think he is wrong by at least
an order of magnitude."                              (Brian Kernighan)

---

From: Tom Lane <[email-masked]>
Date: Mon, 13 Sep 2004 16:39:49 -0400

> evidently never happened.

I said some time ago that I would pester contrib authors about fixing
license issues, but it still hasn't gotten to the top of my to-do list :-(
AFAIK nothing at all has been done on this score.

If Merlin is hot about contrib/userlock right now, he's welcome to try
to contact the original author and get this dealt with.

The point about not importing documentation from a mislicensed contrib
module is valid IMHO.

			regards, tom lane

---

From: Tom Lane <[email-masked]>
Date: Mon, 13 Sep 2004 17:31:15 -0400

> show different data; for example, the PID of the process involved.

I think this is a bad idea, at least for the base-level view, because it
would imply that it's impossible to get a truly simultaneous view of the
state of all the locks.  It would certainly be a bad idea to so separate
xact and table locks.  I'd prefer to extend the present approach and add
columns that are NULL when the type of lock isn't relevant to them.

> lockmethod (1 for system, 2 for user) is used in each lock.

How about a text column with values "TABLE", "XACT", "USER"?

			regards, tom lane