From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 30 Mar 2007 00:13:05 +0000 (+0000)
Subject: Fix oversight in coding of _bt_start_vacuum: we can't assume that the LWLock
X-Git-Url: http://git.postgresql.org/gitweb/static/gitweb.js?a=commitdiff_plain;h=93e34979dfcc7468b27aba670636d4703927794d;p=users%2Fbernd%2Fpostgres.git

Fix oversight in coding of _bt_start_vacuum: we can't assume that the LWLock
will be released by transaction abort before _bt_end_vacuum gets called.
If either of these "can't happen" errors actually happened, we'd freeze up
trying to acquire an already-held lock.  Latest word is that this does
not explain Martin Pitt's trouble report, but it still looks like a bug.
---

diff --git a/src/backend/access/nbtree/nbtutils.c b/src/backend/access/nbtree/nbtutils.c
index 1d9149efa4..a3bff45ecc 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -998,13 +998,25 @@ _bt_start_vacuum(Relation rel)
 		vac = &btvacinfo->vacuums[i];
 		if (vac->relid.relId == rel->rd_lockInfo.lockRelId.relId &&
 			vac->relid.dbId == rel->rd_lockInfo.lockRelId.dbId)
+		{
+			/*
+			 * Unlike most places in the backend, we have to explicitly
+			 * release our LWLock before throwing an error.  This is because
+			 * we expect _bt_end_vacuum() to be called before transaction
+			 * abort cleanup can run to release LWLocks.
+			 */
+			LWLockRelease(BtreeVacuumLock);
 			elog(ERROR, "multiple active vacuums for index \"%s\"",
 				 RelationGetRelationName(rel));
+		}
 	}
 
 	/* OK, add an entry */
 	if (btvacinfo->num_vacuums >= btvacinfo->max_vacuums)
+	{
+		LWLockRelease(BtreeVacuumLock);
 		elog(ERROR, "out of btvacinfo slots");
+	}
 	vac = &btvacinfo->vacuums[btvacinfo->num_vacuums];
 	vac->relid = rel->rd_lockInfo.lockRelId;
 	vac->cycleid = result;