AccessExclusiveLock new relations just after assigning the OID.
authorNoah Misch <[email protected]>
Fri, 28 Jun 2024 02:21:05 +0000 (19:21 -0700)
committerNoah Misch <[email protected]>
Fri, 28 Jun 2024 02:21:05 +0000 (19:21 -0700)
commit5b823b179e5e8ab32f140658698ca08f8c83f06e
tree3b2fc59de9850faf8af1dcf9bd67ab4df3961d04
parent0cecc908e9749101b5e93ba58d76a62c9f226f9e
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]
src/backend/catalog/heap.c