Author:     Noah Misch <noah@leadboat.com>
Commit:     Noah Misch <noah@leadboat.com>

    AccessExclusiveLock new relations just after assigning the OID.
    
    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 by FIXME.
    
    Discussion: https://postgr.es/m/20240512232923.aa.nmisch@google.com

diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index a122bbf..ae2efdc 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -1250,6 +1250,13 @@ heap_create_with_catalog(const char *relname,
 	}
 
 	/*
+	 * 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.
 	 */
 	if (use_user_acl)