Revise lock manager to support "session level" locks as well as "transaction

level" locks.  A session lock is not released at transaction commit (but it
is released on transaction abort, to ensure recovery after an elog(ERROR)).
In VACUUM, use a session lock to protect the master table while vacuuming a
TOAST table, so that the TOAST table can be done in an independent
transaction.

I also took this opportunity to do some cleanup and renaming in the lock
code.  The previously noted bug in ProcLockWakeup, that it couldn't wake up
any waiters beyond the first non-wakeable waiter, is now fixed.  Also found
a previously unknown bug of the same kind (failure to scan all members of
a lock queue in some cases) in DeadLockCheck.  This might have led to failure
to detect a deadlock condition, resulting in indefinite waits, but it's
difficult to characterize the conditions required to trigger a failure.

Author: tglsfdc

contrib/userlock/user_locks.c

@@ -33,7 +33,7 @@ user_lock(uint32 id1, uint32 id2, LOCKMODE lockmode)
 	tag.objId.blkno = (BlockNumber) id2;
 	tag.offnum = (OffsetNumber) (id1 & 0xffff);
 
-	return LockAcquire(USER_LOCKMETHOD, &tag, lockmode);
+	return LockAcquire(USER_LOCKMETHOD, &tag, InvalidTransactionId, lockmode);
 }
 
 int
@@ -47,7 +47,7 @@ user_unlock(uint32 id1, uint32 id2, LOCKMODE lockmode)
 	tag.objId.blkno = (BlockNumber) id2;
 	tag.offnum = (OffsetNumber) (id1 & 0xffff);
 
-	return LockRelease(USER_LOCKMETHOD, &tag, lockmode);
+	return LockRelease(USER_LOCKMETHOD, &tag, InvalidTransactionId, lockmode);
 }
 
 int
@@ -89,7 +89,7 @@ user_unlock_all()
 	}
 
 	proc = (PROC *) MAKE_PTR(location);
-	return LockReleaseAll(USER_LOCKMETHOD, &proc->lockQueue);
+	return LockReleaseAll(USER_LOCKMETHOD, proc, false, InvalidTransactionId);
 }
 
 /* end of file */

src/backend/access/transam/xact.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/access/transam/xact.c,v 1.89 2000/12/18 00:44:45 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/access/transam/xact.c,v 1.90 2000/12/22 00:51:53 tgl Exp $
  *
  * NOTES
  *		Transaction aborts can now occur two ways:
@@ -741,7 +741,7 @@ AtCommit_Locks(void)
 	 *	Then you're up a creek! -mer 5/24/92
 	 * ----------------
 	 */
-	ProcReleaseLocks();
+	ProcReleaseLocks(true);
 }
 
 /* --------------------------------
@@ -828,7 +828,7 @@ AtAbort_Locks(void)
 	 *	Then you're up a creek without a paddle! -mer
 	 * ----------------
 	 */
-	ProcReleaseLocks();
+	ProcReleaseLocks(false);
 }
 
 

src/backend/commands/vacuum.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/commands/vacuum.c,v 1.177 2000/12/08 06:43:44 inoue Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/commands/vacuum.c,v 1.178 2000/12/22 00:51:53 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -61,7 +61,7 @@ static void vacuum_init(void);
 static void vacuum_shutdown(void);
 static void vac_vacuum(NameData *VacRelP, bool analyze, List *anal_cols2);
 static VRelList getrels(NameData *VacRelP);
-static void vacuum_rel(Oid relid, bool is_toastrel);
+static void vacuum_rel(Oid relid);
 static void scan_heap(VRelStats *vacrelstats, Relation onerel, VacPageList vacuum_pages, VacPageList fraged_pages);
 static void repair_frag(VRelStats *vacrelstats, Relation onerel, VacPageList vacuum_pages, VacPageList fraged_pages, int nindices, Relation *Irel);
 static void vacuum_heap(VRelStats *vacrelstats, Relation onerel, VacPageList vacpagelist);
@@ -239,7 +239,7 @@ vac_vacuum(NameData *VacRelP, bool analyze, List *anal_cols2)
 	/* vacuum each heap relation */
 	for (cur = vrl; cur != (VRelList) NULL; cur = cur->vrl_next)
 	{
-		vacuum_rel(cur->vrl_relid, false);
+		vacuum_rel(cur->vrl_relid);
 		/* analyze separately so locking is minimized */
 		if (analyze)
 			analyze_rel(cur->vrl_relid, anal_cols2, MESSAGE_LEVEL);
@@ -308,7 +308,7 @@ getrels(NameData *VacRelP)
 
 		if (rkind != RELKIND_RELATION)
 		{
-			elog(NOTICE, "Vacuum: can not process indecies, views and certain system tables");
+			elog(NOTICE, "Vacuum: can not process indices, views and certain system tables");
 			continue;
 		}
 
@@ -342,32 +342,34 @@ getrels(NameData *VacRelP)
  *	vacuum_rel() -- vacuum one heap relation
  *
  *		This routine vacuums a single heap, cleans out its indices, and
- *		updates its statistics num_pages and num_tuples statistics.
+ *		updates its num_pages and num_tuples statistics.
  *
  *		Doing one heap at a time incurs extra overhead, since we need to
  *		check that the heap exists again just before we vacuum it.	The
  *		reason that we do this is so that vacuuming can be spread across
  *		many small transactions.  Otherwise, two-phase locking would require
  *		us to lock the entire database during one pass of the vacuum cleaner.
+ *
+ *		At entry and exit, we are not inside a transaction.
  */
 static void
-vacuum_rel(Oid relid, bool is_toastrel)
+vacuum_rel(Oid relid)
 {
 	Relation	onerel;
+	LockRelId	onerelid;
 	VacPageListData vacuum_pages; /* List of pages to vacuum and/or clean
-								 * indices */
+								   * indices */
 	VacPageListData fraged_pages; /* List of pages with space enough for
-								 * re-using */
-	VacPage    *vacpage;
+								   * re-using */
 	Relation   *Irel;
 	int32		nindices,
 				i;
 	VRelStats  *vacrelstats;
 	bool		reindex = false;
 	Oid			toast_relid;
 
-	if (!is_toastrel)
-		StartTransactionCommand();
+	/* Begin a transaction for vacuuming this relation */
+	StartTransactionCommand();
 
 	/*
 	 * Check for user-requested abort.	Note we want this to be inside a
@@ -384,8 +386,7 @@ vacuum_rel(Oid relid, bool is_toastrel)
 							  ObjectIdGetDatum(relid),
 							  0, 0, 0))
 	{
-		if (!is_toastrel)
-			CommitTransactionCommand();
+		CommitTransactionCommand();
 		return;
 	}
 
@@ -403,13 +404,25 @@ vacuum_rel(Oid relid, bool is_toastrel)
 		elog(NOTICE, "Skipping \"%s\" --- only table owner can VACUUM it",
 			 RelationGetRelationName(onerel));
 		heap_close(onerel, AccessExclusiveLock);
-		if (!is_toastrel)
-			CommitTransactionCommand();
+		CommitTransactionCommand();
 		return;
 	}
 
 	/*
-	 * Remember the relation'ss TOAST relation for later
+	 * Get a session-level exclusive lock too.  This will protect our
+	 * exclusive access to the relation across multiple transactions,
+	 * so that we can vacuum the relation's TOAST table (if any) secure
+	 * in the knowledge that no one is diddling the parent relation.
+	 *
+	 * NOTE: this cannot block, even if someone else is waiting for access,
+	 * because the lock manager knows that both lock requests are from the
+	 * same process.
+	 */
+	onerelid = onerel->rd_lockInfo.lockRelId;
+	LockRelationForSession(&onerelid, AccessExclusiveLock);
+
+	/*
+	 * Remember the relation's TOAST relation for later
 	 */
 	toast_relid = onerel->rd_rel->reltoastrelid;
 
@@ -500,21 +513,6 @@ vacuum_rel(Oid relid, bool is_toastrel)
 	if (reindex)
 		activate_indexes_of_a_table(relid, true);
 
-	/*
-	 * ok - free vacuum_pages list of reaped pages
-	 *
-	 * Isn't this a waste of code?  Upcoming commit should free memory, no?
-	 */
-	if (vacuum_pages.num_pages > 0)
-	{
-		vacpage = vacuum_pages.pagedesc;
-		for (i = 0; i < vacuum_pages.num_pages; i++, vacpage++)
-			pfree(*vacpage);
-		pfree(vacuum_pages.pagedesc);
-		if (fraged_pages.num_pages > 0)
-			pfree(fraged_pages.pagedesc);
-	}
-
 	/* all done with this class, but hold lock until commit */
 	heap_close(onerel, NoLock);
 
@@ -523,19 +521,25 @@ vacuum_rel(Oid relid, bool is_toastrel)
 					vacrelstats->num_tuples, vacrelstats->hasindex,
 					vacrelstats);
 
+	/*
+	 * Complete the transaction and free all temporary memory used.
+	 */
+	CommitTransactionCommand();
+
 	/*
 	 * If the relation has a secondary toast one, vacuum that too
-	 * while we still hold the lock on the master table. We don't
-	 * need to propagate "analyze" to it, because the toaster
+	 * while we still hold the session lock on the master table.
+	 * We don't need to propagate "analyze" to it, because the toaster
 	 * always uses hardcoded index access and statistics are
 	 * totally unimportant for toast relations
 	 */
 	if (toast_relid != InvalidOid)
-		vacuum_rel(toast_relid, true);
+		vacuum_rel(toast_relid);
 
-	/* next command frees attribute stats */
-	if (!is_toastrel)
-		CommitTransactionCommand();
+	/*
+	 * Now release the session-level lock on the master table.
+	 */
+	UnlockRelationForSession(&onerelid, AccessExclusiveLock);
 }
 
 /*
@@ -1786,9 +1790,13 @@ failed to add item with len = %lu to page %u (free space %lu, nusd %u, noff %u)"
 	if (num_moved > 0)
 	{
 		/*
-		 * We have to commit our tuple' movings before we'll truncate
-		 * relation, but we shouldn't lose our locks. And so - quick hack:
-		 * record status of current transaction as committed, and continue.
+		 * We have to commit our tuple movings before we truncate the
+		 * relation.  Ideally we should do Commit/StartTransactionCommand
+		 * here, relying on the session-level table lock to protect our
+		 * exclusive access to the relation.  However, that would require
+		 * a lot of extra code to close and re-open the relation, indices,
+		 * etc.  For now, a quick hack: record status of current transaction
+		 * as committed, and continue.
 		 */
 		RecordTransactionCommit();
 	}
@@ -1852,7 +1860,7 @@ failed to add item with len = %lu to page %u (free space %lu, nusd %u, noff %u)"
 	/* 
 	 * Reflect the motion of system tuples to catalog cache here.
 	 */
-        CommandCounterIncrement();
+	CommandCounterIncrement();
 
 	if (Nvacpagelist.num_pages > 0)
 	{

src/backend/storage/ipc/ipci.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/storage/ipc/ipci.c,v 1.37 2000/12/03 17:18:10 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/storage/ipc/ipci.c,v 1.38 2000/12/22 00:51:54 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -84,7 +84,7 @@ CreateSharedMemoryAndSemaphores(bool makePrivate, int maxBackends)
 	 * Set up lock manager
 	 */
 	InitLocks();
-	if (InitLockTable() == INVALID_TABLEID)
+	if (InitLockTable(maxBackends) == INVALID_TABLEID)
 		elog(FATAL, "Couldn't create the lock table");
 
 	/*

src/backend/storage/lmgr/README

@@ -1,8 +1,15 @@
-$Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.3 1998/07/06 18:16:07 momjian Exp $
+$Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.4 2000/12/22 00:51:54 tgl Exp $
 
-There are two fundemental lock structures.  Lock methods describe the
-locking behavior.  We currently only support multi-level locking.  Lock
-modes describe the mode of the lock(read/write or shared/exclusive). 
+There are two fundamental lock structures: the per-lockable-object LOCK
+struct, and the per-lock-holder HOLDER struct.  A LOCK object exists
+for each lockable object that currently has locks held or requested on it.
+A HOLDER struct exists for each transaction that is holding or requesting
+lock(s) on each LOCK object.
+
+Lock methods describe the overall locking behavior.  Currently there are
+two lock methods: DEFAULT and USER.  (USER locks are non-blocking.)
+
+Lock modes describe the type of the lock (read/write or shared/exclusive). 
 See src/tools/backend/index.html and src/include/storage/lock.h for more
 details.
 
@@ -12,10 +19,10 @@ The lock manager's LOCK:
 
 tag -
     The key fields that are used for hashing locks in the shared memory
-    lock hash table.  This is kept as a separate struct to ensure that we
-    always zero out the correct number of bytes.  This is a problem as
-    part of the tag is an itempointer which is 6 bytes and causes 2
-    additional bytes to be added as padding.
+    lock hash table.  This is declared as a separate struct to ensure that
+    we always zero out the correct number of bytes.  It is critical that
+    any alignment-padding bytes the compiler might insert in the struct
+    be zeroed out, else the hash computation will be random.
 
     tag.relId -
 	Uniquely identifies the relation that the lock corresponds to.
@@ -30,17 +37,17 @@ tag -
 	tuple within the block.  If we are setting a table level lock
 	both the blockId and tupleId (in an item pointer this is called
 	the position) are set to invalid, if it is a page level lock the
-	blockId is valid, while the tuleId is still invalid.  Finally if
+	blockId is valid, while the tupleId is still invalid.  Finally if
 	this is a tuple level lock (we currently never do this) then both
 	the blockId and tupleId are set to valid specifications.  This is
 	how we get the appearance of a multi-level lock table while using
 	only a single table (see Gray's paper on 2 phase locking if
 	you are puzzled about how multi-level lock tables work).
 
 mask -
-    This field indicates what types of locks are currently held in the
-    given lock.  It is used (against the lock table's conflict table)
-    to determine if the new lock request will conflict with existing
+    This field indicates what types of locks are currently held on the
+    given lockable object.  It is used (against the lock table's conflict
+    table) to determine if the new lock request will conflict with existing
     lock types held.  Conficts are determined by bitwise AND operations
     between the mask and the conflict table entry for the given lock type
     to be set.  The current representation is that each bit (1 through 5)
@@ -73,7 +80,7 @@ holders -
 
 nActive -
     Keeps a count of how many times this lock has been succesfully acquired.
-    This count does not include attempts that were rejected due to conflicts,
+    This count does not include attempts that are waiting due to conflicts,
     but can count the same backend twice (e.g. a read then a write -- since
     its the same transaction this won't cause a conflict)
 
@@ -85,3 +92,39 @@ activeHolders -
 
 ---------------------------------------------------------------------------
 
+The lock manager's HOLDER:
+
+tag -
+    The key fields that are used for hashing entries in the shared memory
+    holder hash table.  This is declared as a separate struct to ensure that
+    we always zero out the correct number of bytes.
+
+    tag.lock
+        SHMEM offset of the LOCK object this holder is for.
+
+    tag.pid
+        PID of backend process that owns this holder.
+
+    tag.xid
+        XID of transaction this holder is for, or InvalidTransactionId
+        if the holder is for session-level locking.
+
+    Note that this structure will support multiple transactions running
+    concurrently in one backend, which may be handy if we someday decide
+    to support nested transactions.  Currently, the XID field is only needed
+    to distinguish per-transaction locks from session locks.  User locks
+    are always session locks, and we also use session locks for multi-
+    transaction operations like VACUUM.
+
+holders -
+    The number of successfully acquired locks of each type for this holder.
+    (CAUTION: the semantics are not the same as the LOCK's holder[], which
+    counts both acquired and pending requests.  Probably a different name
+    should be used...)
+
+nHolding -
+    Sum of the holders[] array.
+
+queue -
+    List link for shared memory queue of all the HOLDER objects for the
+    same backend.