mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-11-21 03:13:05 +08:00
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.9f.nmisch@google.com
This commit is contained in:
parent
480b58fabd
commit
fc8c25806e
@ -1239,6 +1239,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.
|
||||
*/
|
||||
|
Loading…
Reference in New Issue
Block a user