AccessExclusiveLock new relations just after assigning the OID.

nmisch · nmisch · commit b899cde0b86a · 2024-06-27T19:21:12.000-07:00
This has no user-visible, important consequences, since other sessions' catalog scans can't find the relation until we commit. However, this unblocks introducing a rule about locks required to heap_update() a pg_class row. CREATE TABLE has been acquiring this lock eventually, but it can heap_update() pg_class.relchecks earlier. create_toast_table() has been acquiring only ShareLock. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmisch@google.com
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
@@ -1226,6 +1226,13 @@ heap_create_with_catalog(const char *relname,
 									  relpersistence);
 	}
 
+	/*
+	 * Other sessions' catalog scans can't find this until we commit.  Hence,
+	 * it doesn't hurt to hold AccessExclusiveLock.  Do it here so callers
+	 * can't accidentally vary in their lock mode or acquisition timing.
+	 */
+	LockRelationOid(relid, AccessExclusiveLock);
+
 	/*
 	 * Determine the relation's initial permissions.
 	 */
