Simplify lock manager data structures by making a clear separation between

the data defining the semantics of a lock method (ie, conflict resolution
table and ancillary data, which is all constant) and the hash tables
storing the current state.  The only thing we give up by this is the
ability to use separate hashtables for different lock methods, but there
is no need for that anyway.  Put some extra fields into the LockMethod
definition structs to clean up some other uglinesses, like hard-wired
tests for DEFAULT_LOCKMETHOD and USER_LOCKMETHOD.  This commit doesn't
do anything about the performance issues we were discussing, but it clears
away some of the underbrush that's in the way of fixing that.

Author: tglsfdc

contrib/userlock/user_locks.c

@@ -23,7 +23,8 @@
 	 (locktag).locktag_field2 = (id1), \
 	 (locktag).locktag_field3 = (id2), \
 	 (locktag).locktag_field4 = 0, \
-	 (locktag).locktag_type = LOCKTAG_USERLOCK)
+	 (locktag).locktag_type = LOCKTAG_USERLOCK, \
+	 (locktag).locktag_lockmethodid = USER_LOCKMETHOD)
 
 
 int
@@ -33,7 +34,7 @@ user_lock(uint32 id1, uint32 id2, LOCKMODE lockmode)
 
 	SET_LOCKTAG_USERLOCK(tag, id1, id2);
 
-	return (LockAcquire(USER_LOCKMETHOD, &tag, false,
+	return (LockAcquire(&tag, false,
 						lockmode, true, true) != LOCKACQUIRE_NOT_AVAIL);
 }
 
@@ -44,7 +45,7 @@ user_unlock(uint32 id1, uint32 id2, LOCKMODE lockmode)
 
 	SET_LOCKTAG_USERLOCK(tag, id1, id2);
 
-	return LockRelease(USER_LOCKMETHOD, &tag, lockmode, true);
+	return LockRelease(&tag, lockmode, true);
 }
 
 int

src/backend/storage/ipc/ipci.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/storage/ipc/ipci.c,v 1.79 2005/10/15 02:49:25 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/storage/ipc/ipci.c,v 1.80 2005/12/09 01:22:03 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -25,7 +25,7 @@
 #include "storage/bufmgr.h"
 #include "storage/freespace.h"
 #include "storage/ipc.h"
-#include "storage/lmgr.h"
+#include "storage/lock.h"
 #include "storage/lwlock.h"
 #include "storage/pg_sema.h"
 #include "storage/pg_shmem.h"
@@ -159,7 +159,6 @@ CreateSharedMemoryAndSemaphores(bool makePrivate, int port)
 	 * Set up lock manager
 	 */
 	InitLocks();
-	InitLockTable();
 
 	/*
 	 * Set up process table

src/backend/storage/lmgr/README

@@ -1,4 +1,4 @@
-$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.17 2005/06/14 22:15:32 tgl Exp $
+$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.18 2005/12/09 01:22:04 tgl Exp $
 
 
 LOCKING OVERVIEW
@@ -151,7 +151,7 @@ tag -
         SHMEM offset of the LOCK object this PROCLOCK is for.
 
     tag.proc
-        SHMEM offset of PROC of backend process that owns this PROCLOCK.
+        SHMEM offset of PGPROC of backend process that owns this PROCLOCK.
 
 holdMask -
     A bitmask for the lock types successfully acquired by this PROCLOCK.
@@ -415,3 +415,26 @@ seems a safer approach than trying to allocate workspace on the fly; we
 don't want to risk having the deadlock detector run out of memory, else
 we really have no guarantees at all that deadlock will be detected.
 
+
+USER LOCKS
+
+User locks are handled totally on the application side as long term
+cooperative locks which extend beyond the normal transaction boundaries.
+Their purpose is to indicate to an application that someone is `working'
+on an item.  So it is possible to put an user lock on a tuple's oid,
+retrieve the tuple, work on it for an hour and then update it and remove
+the lock.  While the lock is active other clients can still read and write
+the tuple but they can be aware that it has been locked at the application
+level by someone.
+
+User locks and normal locks are completely orthogonal and they don't
+interfere with each other.
+
+User locks are always non blocking, therefore they are never acquired if
+already held by another process.  They must be released explicitly by the
+application but they are released automatically when a backend terminates.
+
+The lockmode parameter can have the same values as for normal locks although
+probably only ExclusiveLock can have some practical use.
+
+	DZ - 22 Nov 1997

src/backend/storage/lmgr/deadlock.c

@@ -12,7 +12,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/storage/lmgr/deadlock.c,v 1.36 2005/10/29 00:31:51 petere Exp $
+ *	  $PostgreSQL: pgsql/src/backend/storage/lmgr/deadlock.c,v 1.37 2005/12/09 01:22:04 tgl Exp $
  *
  *	Interface:
  *
@@ -930,7 +930,8 @@ DeadLockReport(void)
 		appendStringInfo(&buf,
 				  _("Process %d waits for %s on %s; blocked by process %d."),
 						 info->pid,
-						 GetLockmodeName(info->lockmode),
+						 GetLockmodeName(info->locktag.locktag_lockmethodid,
+										 info->lockmode),
 						 buf2.data,
 						 nextpid);
 	}