inplace075-lock-heap_create-v2.patch
text/plain
Filename: inplace075-lock-heap_create-v2.patch
Type: text/plain
Part: 7
Message:
Re: race condition in pg_class
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: unified
Series: patch v2
| File | + | − |
|---|---|---|
| src/backend/catalog/heap.c | 7 | 0 |
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 922ba79..fbad1d2 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)