database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-17 06:41:24 +03:00
Code

AccessExclusiveLock new relations just after assigning the OID.

Browse Source 
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
This commit is contained in:
Noah Misch 2024-06-27 19:21:05 -07:00
parent 1a6d65b64e
commit b899cde0b8
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/backend/catalog/heap.c
View File

@ -1226,6 +1226,13 @@ heap_create_with_catalog(const char *relname,
relpersistence); 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. * Determine the relation's initial permissions.
*/ */