Locking and Tables

PostgreSQL 7.2 Documentation
Prev | Chapter 9. Multiversion Concurrency Control | Next

# 9.6. Locking and Tables

PostgreSQL provides various lock modes to control concurrent access to data in tables. Some of these lock modes are acquired by PostgreSQL automatically before statement execution, while others are provided to be used by applications. All lock modes acquired in a transaction are held for the duration of the transaction.

## 9.6.1. Table-level locks

AccessShareLock

  A read-lock mode acquired automatically on tables being queried.

  Conflicts with AccessExclusiveLock only.

RowShareLock

  Acquired by SELECT FOR UPDATE and LOCK TABLE for `IN ROW SHARE MODE` statements.

  Conflicts with ExclusiveLock and AccessExclusiveLock modes.

RowExclusiveLock

  Acquired by UPDATE, DELETE, INSERT and LOCK TABLE for `IN ROW EXCLUSIVE MODE` statements.

  Conflicts with ShareLock, ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock modes.

ShareUpdateExclusiveLock

  Acquired by VACUUM (without `FULL`) and LOCK TABLE table for `IN SHARE UPDATE EXCLUSIVE MODE` statements.

  Conflicts with ShareUpdateExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock modes.

ShareLock

  Acquired by CREATE INDEX and LOCK TABLE table for `IN SHARE MODE` statements.

  Conflicts with RowExclusiveLock, ShareUpdateExclusiveLock, ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock modes.

ShareRowExclusiveLock

  Acquired by LOCK TABLE for `IN SHARE ROW EXCLUSIVE MODE` statements.

  Conflicts with RowExclusiveLock, ShareUpdateExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock modes.

ExclusiveLock

  Acquired by LOCK TABLE table for `IN EXCLUSIVE MODE` statements.

  Conflicts with RowShareLock, RowExclusiveLock, ShareUpdateExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock modes.

AccessExclusiveLock

  Acquired by ALTER TABLE, DROP TABLE, VACUUM FULL and LOCK TABLE statements.

  Conflicts with all modes (AccessShareLock, RowShareLock, RowExclusiveLock, ShareUpdateExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock).

> Note: Only AccessExclusiveLock blocks SELECT (without `FOR UPDATE`) statement.

## 9.6.2. Row-level locks

Row-level locks are acquired when rows are being updated (or deleted or marked for update). Row-level locks don't affect data querying. They block writers to the same row only.

PostgreSQL doesn't remember any information about modified rows in memory and so has no limit to the number of rows locked at one time. However, locking a row may cause a disk write; thus, for example, SELECT FOR UPDATE will modify selected rows to mark them and so will result in disk writes.

In addition to table and row locks, short-term share/exclusive locks are used to control read/write access to table pages in the shared buffer pool. These locks are released immediately after a tuple is fetched or updated. Application writers normally need not be concerned with page-level locks, but we mention them for completeness.

Prev | Home | Next
Data consistency checks at the application level | Up | Locking and Indexes