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 (in an earlier version) by Robert Haas.

Discussion: https://postgr.es/m/20240611024525[email protected]

diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index a122bbffce771896cf0640ed57016b3980f0e6c4..ae2efdc760d19b40417995713e4bafafe9b9f8ef 100644 (file)
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -1249,6 +1249,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.
     */