- provides various lock modes to control concurrent
- access to data in tables. Some of these lock modes are acquired by
- 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.
+
PostgreSQL provides various lock modes+ to control concurrent access to data in tables. Users normally
+ need not be concerned about the different lock modes because
+
PostgreSQL commands automatically+ acquire locks of appropriate modes to ensure data integrity while
+ permitting an appropriate level of concurrent access.
+ Nevertheless, a user can manually lock a table in any of the
+ available modes using the LOCK TABLE command.
-
-
Table-level locks
+ The list below shows the available lock modes and the contexts in
+ which they are used. Remember that all of these lock modes are
+ table-level locks, even if the name contains the word
+ row
. The names of the lock modes are historical.
+
+
Table-level lock modes
- AccessShareLock
+ ACCESS SHARE
- Conflicts with AccessExclusiveLock only.
+ Conflicts with the ACCESS EXCLUSIVE lock
+ mode only.
- RowShareLock
+ ROW SHARE
- Acquired by SELECT FOR UPDATE
- and LOCK TABLE
- statements.
+ The SELECT FOR UPDATE command acquires a
+ lock of this mode.
- Conflicts with ExclusiveLock and AccessExclusiveLock modes.
+ Conflicts with the EXCLUSIVE and
+ ACCESS EXCLUSIVE lock modes.
- RowExclusiveLock
+ ROW EXCLUSIVE
- Acquired by UPDATE, DELETE,
- INSERT and LOCK TABLE
- statements.
+ The commands UPDATE,
+ DELETE, and INSERT
+ automatically acquire this lock mode.
- Conflicts with ShareLock, ShareRowExclusiveLock, ExclusiveLock and
- AccessExclusiveLock modes.
+ Conflicts with the SHARE, SHARE ROW
+ EXCLUSIVE, EXCLUSIVE, and
+ ACCESS EXCLUSIVE lock modes.
- ShareUpdateExclusiveLock
+ SHARE UPDATE EXCLUSIVE
- Acquired by VACUUM (without )
- and LOCK TABLE
-
- statements.
+ Acquired by VACUUM (without ).
- Conflicts with ShareUpdateExclusiveLock, ShareLock,
- ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock modes.
+ Conflicts with the SHARE UPDATE EXCLUSIVE,
+ SHARE, SHARE ROW
+ EXCLUSIVE, EXCLUSIVE, and
+ ACCESS EXCLUSIVE lock modes.
- ShareLock
+ SHARE
- Acquired by CREATE INDEX
- and LOCK TABLE
-
- statements.
+ Acquired by CREATE INDEX.
- Conflicts with RowExclusiveLock, ShareUpdateExclusiveLock,
- ShareRowExclusiveLock,
- ExclusiveLock and AccessExclusiveLock modes.
+ Conflicts with the ROW EXCLUSIVE,
+ SHARE UPDATE EXCLUSIVE, SHARE ROW
+ EXCLUSIVE, EXCLUSIVE, and
+ ACCESS EXCLUSIVE lock modes.
- ShareRowExclusiveLock
+ SHARE ROW EXCLUSIVE
- Acquired by LOCK TABLE
- statements.
+ This lock mode is not automatically acquired by any command.
- Conflicts with RowExclusiveLock, ShareUpdateExclusiveLock,
- ShareLock, ShareRowExclusiveLock,
- ExclusiveLock and AccessExclusiveLock modes.
+ Conflicts with the ROW EXCLUSIVE,
+ SHARE UPDATE EXCLUSIVE,
+ SHARE, SHARE ROW
+ EXCLUSIVE, EXCLUSIVE, and
+ ACCESS EXCLUSIVE lock modes.
- ExclusiveLock
+ EXCLUSIVE LOCK
- Acquired by LOCK TABLE
- statements.
+ This lock mode is not automatically acquired by any command.
- Conflicts with RowShareLock, RowExclusiveLock,
- ShareUpdateExclusiveLock, ShareLock,
- ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock
- modes.
+ Conflicts with the ROW SHARE, ROW
+ EXCLUSIVE, SHARE UPDATE
+ EXCLUSIVE, SHARE, SHARE
+ ROW EXCLUSIVE, EXCLUSIVE, and
+ ACCESS EXCLUSIVE lock modes.
- AccessExclusiveLock
+ ACCESS EXCLUSIVE
- Acquired by ALTER TABLE,
- DROP TABLE,
- VACUUM FULL and LOCK TABLE
- (or plain
- LOCK TABLE) statements.
+ Acquired by the ALTER TABLE, DROP
+ TABLE, and VACUUM FULL commands.
+ This is also the default lock mode for LOCK TABLE
+ statements that do not specify a mode explicitly.
- Conflicts with all modes (AccessShareLock, RowShareLock,
- RowExclusiveLock, ShareUpdateExclusiveLock, ShareLock,
- ShareRowExclusiveLock, ExclusiveLock and AccessExclusiveLock).
+ Conflicts with locks of all modes ( ACCESS
+ SHARE, ROW SHARE, ROW
+ EXCLUSIVE, SHARE UPDATE
+ EXCLUSIVE, SHARE, SHARE
+ ROW EXCLUSIVE, EXCLUSIVE, and
+ ACCESS EXCLUSIVE).
- Only AccessExclusiveLock blocks SELECT (without
- ) statement.
+ Only an ACCESS EXCLUSIVE lock blocks a
+ SELECT (without )
+ statement.
-
-
-
-
-
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.
+ In addition to table-level locks, there are 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. Row-level locks cannot be acquired explicitly by the user.
- 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.
+
PostgreSQL doesn't remember any+ information about modified rows in memory, so is 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.
updated. Application writers normally need not be concerned with
page-level locks, but we mention them for completeness.
-
projects / postgresql.git / commitdiff