Conflicts with the ACCESS EXCLUSIVE lock mode only.
The SELECT command acquires a lock of this mode on referenced tables. In general, any query that only reads a table and does not modify it will acquire this lock mode.
Conflicts with the EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
The SELECT command acquires a lock of this mode on all tables on which one of the FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE, or FOR KEY SHARE options is specified (in addition to ACCESS SHARE locks on any other tables that are referenced without any explicit FOR ... locking option).
Conflicts with the SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE lock modes.
The commands UPDATE, DELETE, INSERT, and MERGE acquire this lock mode on the target table (in addition to ACCESS SHARE locks on any other referenced tables). In general, this lock mode will be acquired by any command that modifies data in a table.
Conflicts with the SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE lock modes. This mode protects a table against concurrent schema changes and VACUUM runs.
Acquired by VACUUM (without FULL), ANALYZE, CREATE INDEX CONCURRENTLY, CREATE STATISTICS, COMMENT ON, REINDEX CONCURRENTLY, and certain ALTER INDEX and ALTER TABLE variants (for full details see the documentation of these commands).
Conflicts with the ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE lock modes. This mode protects a table against concurrent data changes.
Acquired by CREATE INDEX (without CONCURRENTLY).
Conflicts with the ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE lock modes. This mode protects a table against concurrent data changes, and is self-exclusive so that only one session can hold it at a time.
Acquired by CREATE TRIGGER and some forms of ALTER TABLE.
Conflicts with the ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE lock modes. This mode allows only concurrent ACCESS SHARE locks, i.e., only reads from the table can proceed in parallel with a transaction holding this lock mode.
Acquired by REFRESH MATERIALIZED VIEW CONCURRENTLY.
Conflicts with locks of all modes (ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE). This mode guarantees that the holder is the only transaction accessing the table in any way.
Acquired by the DROP TABLE, TRUNCATE, REINDEX, CLUSTER, VACUUM FULL, and REFRESH MATERIALIZED VIEW (without CONCURRENTLY) commands. Many forms of ALTER INDEX and ALTER TABLE also acquire a lock at this level. This is also the default lock mode for LOCK TABLE statements that do not specify a mode explicitly.
Behaves similarly to FOR SHARE, except that the lock is weaker: SELECT FOR UPDATE is blocked, but not SELECT FOR NO KEY UPDATE. A key-shared lock blocks other transactions from performing DELETE or any UPDATE that changes the key values, but not other UPDATE, and neither does it prevent SELECT FOR NO KEY UPDATE, SELECT FOR SHARE, or SELECT FOR KEY SHARE.
Behaves similarly to FOR NO KEY UPDATE, except that it acquires a shared lock rather than exclusive lock on each retrieved row. A shared lock blocks other transactions from performing UPDATE, DELETE, SELECT FOR UPDATE or SELECT FOR NO KEY UPDATE on these rows, but it does not prevent them from performing SELECT FOR SHARE or SELECT FOR KEY SHARE.
Behaves similarly to FOR UPDATE, except that the lock acquired is weaker: this lock will not block SELECT FOR KEY SHARE commands that attempt to acquire a lock on the same rows. This lock mode is also acquired by any UPDATE that does not acquire a FOR UPDATE lock.
FOR UPDATE causes the rows retrieved by the SELECT statement to be locked as though for update. This prevents them from being locked, modified or deleted by other transactions until the current transaction ends. That is, other transactions that attempt UPDATE, DELETE, SELECT FOR UPDATE, SELECT FOR NO KEY UPDATE, SELECT FOR SHARE or SELECT FOR KEY SHARE of these rows will be blocked until the current transaction ends; conversely, SELECT FOR UPDATE will wait for a concurrent transaction that has run any of those commands on the same row, and will then lock and return the updated row (or no row, if the row was deleted). Within a REPEATABLE READ or SERIALIZABLE transaction, however, an error will be thrown if a row to be locked has changed since the transaction started. For further discussion see Data Consistency Checks at the Application Level.
The FOR UPDATE lock mode is also acquired by any DELETE on a row, and also by an UPDATE that modifies the values of certain columns. Currently, the set of columns considered for the UPDATE case are those that have a unique index on them that can be used in a foreign key (so partial indexes and expressional indexes are not considered), but this may change in the future.
The write target takes ROW EXCLUSIVE. The foreign-key check takes ROW SHARE and FOR KEY SHARE on a different object: the referenced table and its matching rows. 来源
The write target takes ROW EXCLUSIVE. The foreign-key check takes ROW SHARE and FOR KEY SHARE on a different object: the referenced table and its matching rows. 来源
The write target takes ROW EXCLUSIVE. The foreign-key check takes ROW SHARE and FOR KEY SHARE on a different object: the referenced table and its matching rows. 来源
The write target takes ROW EXCLUSIVE. The foreign-key check takes ROW SHARE and FOR KEY SHARE on a different object: the referenced table and its matching rows. 来源
From PostgreSQL 12, session-level SHARE UPDATE EXCLUSIVE locks cover the rebuilt index and its table through the build, validation, swap and cleanup transactions. 来源
The parent lock is extracted separately for every version. The table being attached additionally requires ACCESS EXCLUSIVE. From PostgreSQL 11 a default partition, if any, is also locked. 来源
From PostgreSQL 14, concurrent detach uses two transactions. The parent holds SHARE UPDATE EXCLUSIVE and waits for transactions using the partition before finalizing. 来源
Ordinary REINDEX takes SHARE on the table and ACCESS EXCLUSIVE on the index itself. The index lock is not an ACCESS EXCLUSIVE lock on the whole table. 来源
Ordinary VACUUM briefly attempts ACCESS EXCLUSIVE when returning empty tail pages to the operating system. Where supported, disabling truncation avoids this phase. 来源
From PostgreSQL 11, an existing default partition requires ACCESS EXCLUSIVE. An appropriate CHECK constraint can avoid a scan but not the lock on the default partition. Descendant scanning follows validation needs. 来源
Checking a non-null foreign key locks matching rows in the referenced table FOR KEY SHARE. The check can run immediately or be deferred. Cascading actions require their own UPDATE or DELETE locks. 来源
Checking a non-null foreign key locks matching rows in the referenced table FOR KEY SHARE. The check can run immediately or be deferred. Cascading actions require their own UPDATE or DELETE locks. 来源
Checking a non-null foreign key locks matching rows in the referenced table FOR KEY SHARE. The check can run immediately or be deferred. Cascading actions require their own UPDATE or DELETE locks. 来源
Checking a non-null foreign key locks matching rows in the referenced table FOR KEY SHARE. The check can run immediately or be deferred. Cascading actions require their own UPDATE or DELETE locks. 来源
UPDATE uses this mode when it does not require FOR UPDATE. Key columns are columns of a unique index usable by a foreign key; partial and expression indexes do not qualify. 来源
The conflict action updates key columns of an existing row. This is not a fixed row lock for every INSERT. 来源
没有匹配命令,请尝试更短的关键词。
From compatibility to actual waits
Ordinary SELECT uses MVCC and takes ACCESS SHARE on referenced tables, without taking these row locks.
SELECT FOR also takes ROW SHARE; UPDATE and DELETE also take ROW EXCLUSIVE. A row operation can therefore wait on a table lock.
The matrix compares different transactions. Locks are normally held until transaction end; rolling back to a savepoint releases locks acquired since that savepoint.
Foreign keys, triggers, additional objects, lock queues and transaction snapshots can introduce waits beyond the listed modes. NOWAIT and SKIP LOCKED change waiting behavior.
Advisory locks, predicate locks and internal lightweight locks are separate mechanisms. See Explicit Locking and pg_locks.
Find blocking sessions
pg_blocking_pids() considers both holders of conflicting locks and conflicting requests ahead in the queue.
SELECT pid, usename, wait_event_type, wait_event,
pg_blocking_pids(pid) AS blocking_pids, query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0
ORDER BY pid;
Visibility of sessions and query text depends on privileges. Individual row locks normally do not appear in pg_locks; a row-lock wait often appears as waiting for the holding transaction.