The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.4/explicit-locking.html Description:
Hi The "13.3.1. Table-level Locks" subsection mentions the following: "Once acquired, a lock is normally held till end of transaction." (maybe we should also squeeze a "...till the end of a transaction" in there) According to a helpful stranger on IRC, this behaviour is also true for row-level locks. Since this sentence also applies to the row-level locks described in the following subsection 13.3.2 I think it would be more fitting to move the paragraph containing this sentence to the introduction of the topic in section "13.3. Explicit Locking". This would then read something like: --- 13.3. Explicit Locking PostgreSQL provides various lock modes to control concurrent access to data in tables. These modes can be used for application-controlled locking in situations where MVCC does not give the desired behavior. Also, most PostgreSQL commands automatically acquire locks of appropriate modes to ensure that referenced tables are not dropped or modified in incompatible ways while the command executes. (For example, TRUNCATE cannot safely be executed concurrently with other operations on the same table, so it obtains an exclusive lock on the table to enforce that.) Such explicit locks are normally held till the end of a transaction. But if a lock is acquired after establishing a savepoint, the lock is released immediately if the savepoint is rolled back to. This is consistent with the principle that ROLLBACK cancels all effects of the commands since the savepoint. The same holds for locks acquired within a PL/pgSQL exception block: an error escape from the block releases locks acquired within it. To examine a list of the currently outstanding locks in a database server, use the pg_locks system view. For more information on monitoring the status of the lock manager subsystem, refer to Chapter 28. --- What do you think? Cheers, Silvan