More cleanup after failed reduced-lock-levels-for-DDL feature.

tglsfdc · tglsfdc · commit dff178f8017e · 2011-10-21T13:49:58.000-04:00
Turns out that use of ShareUpdateExclusiveLock or ShareRowExclusiveLock
to protect DDL changes had gotten copied into several places that were
not touched by either of Simon's original patches for the feature, and
thus neither he nor I thought to revert them.  (Indeed, it appears that
two of these uses were committed *after* the reversion, which just goes
to show that git merging is no panacea.)  Change these places to use
AccessExclusiveLock again.  If we ever manage to resurrect that feature,
we're going to have to think a bit harder about how to keep lock level
usage in sync for DDL operations that aren't within the AlterTable
infrastructure.

Two of these bugs are only in HEAD, but one is in the 9.1 branch too.
Alvaro found one of them, I found the other two.
diff --git a/src/backend/catalog/toasting.c b/src/backend/catalog/toasting.c
@@ -59,11 +59,13 @@ AlterTableCreateToastTable(Oid relOid, Datum reloptions)
 	Relation	rel;
 
 	/*
-	 * Grab a DDL-exclusive lock on the target table, since we'll update the
-	 * pg_class tuple.	This is redundant for all present users.  Tuple
-	 * toasting behaves safely in the face of a concurrent TOAST table add.
+	 * Grab an exclusive lock on the target table, since we'll update its
+	 * pg_class tuple. This is redundant for all present uses, since caller
+	 * will have such a lock already.  But the lock is needed to ensure that
+	 * concurrent readers of the pg_class tuple won't have visibility issues,
+	 * so let's be safe.
 	 */
-	rel = heap_open(relOid, ShareUpdateExclusiveLock);
+	rel = heap_open(relOid, AccessExclusiveLock);
 
 	/* create_toast_table does all the work */
 	(void) create_toast_table(rel, InvalidOid, InvalidOid, reloptions);
