Lock:relation
This event occurs when a process is waiting to acquire a heavyweight lock on a database object—most commonly a table, but it could also be an index, view, or sequence.
Unlike the "Lightweight" locks (like BufferContent or BufferIO) which protect memory or I/O and last for microseconds, Relation locks are "Heavyweight" locks that protect the logical structure and data integrity of your tables.
They can last for the entire duration of a transaction.
What does it mean?
In PostgreSQL, every query requires a certain "Lock Mode" on a table to ensure that someone else doesn't change the rules while the query is running.
- You see the relation wait event when Session A holds a lock that is incompatible with the lock requested by Session B.
- PostgreSQL maintains a lock queue. If Session B's request is blocked, it sits in the relation wait state until Session A either COMMITs or ROLLBACKs.
Common scenarios when this occurs:
- Conflicting statements (The most common cause).
For example, if you try to change the structure of a table (DDL) while queries are running, you will see this wait.
- Explicit Table Locking.
If your application code explicitly calls LOCK TABLE name IN EXCLUSIVE MODE, any other process trying to access that table will enter the relation wait state.
- Heavy Maintenance Tasks.Operations like VACUUM FULL, CLUSTER, or REINDEX (without the CONCURRENTLY keyword) require exclusive access to the relation. If these tasks are running, all other users trying to access those tables will be blocked.