From: Tom Lane Date: Fri, 18 Jan 2002 01:05:43 +0000 (+0000) Subject: Explain privileges required for LOCK. Minor wordsmithing too. X-Git-Tag: REL7_2_RC1~18 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=1d174c3086b5567449e1843ec8296405e7845dc4;p=postgresql Explain privileges required for LOCK. Minor wordsmithing too. --- diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml index 055977f745..50823f0874 100644 --- a/doc/src/sgml/ref/lock.sgml +++ b/doc/src/sgml/ref/lock.sgml @@ -1,5 +1,5 @@ @@ -76,8 +76,7 @@ where lockmode is one of: - Automatically acquired by SELECT...FOR UPDATE. - While it is a shared lock, may be upgraded later to a ROW EXCLUSIVE lock. + Automatically acquired by SELECT ... FOR UPDATE. @@ -175,6 +174,9 @@ where lockmode is one of: Conflicts with ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE modes. + This mode allows only concurrent ACCESS SHARE, i.e., only reads + from the table can proceed in parallel with a transaction holding + this lock mode. @@ -225,7 +227,7 @@ LOCK TABLE - The lock was successfully applied. + The lock was successfully acquired. @@ -310,23 +312,26 @@ ERROR name: Table does not exist. - For example, an application runs a transaction at READ COMMITTED isolation - level and needs to ensure the existence of data in a table for the - duration of the - transaction. To achieve this you could use SHARE lock mode over the - table before querying. This will protect data from concurrent changes - and provide any further read operations over the table with data in their - actual current state, because SHARE lock mode conflicts with any ROW EXCLUSIVE - one acquired by writers, and your + For example, suppose an application runs a transaction at READ COMMITTED + isolation level and needs to ensure the existence of data in a table for + the duration of the + transaction. To achieve this you could obtain SHARE lock mode over the + table before querying. This will prevent concurrent data changes + and ensure further read operations over the table see data in their + actual current state, because SHARE lock mode conflicts with any ROW + EXCLUSIVE lock acquired by writers, and your LOCK TABLE name IN SHARE MODE - statement will wait until any concurrent write operations commit or rollback. + statement will wait until any concurrent write operations commit or + rollback. Thus, once you obtain the lock, there are no uncommitted + writes outstanding. - To read data in their real current state when running a transaction - at the SERIALIZABLE isolation level you have to execute a LOCK TABLE - statement before executing any DML statement, when the transaction defines - what concurrent changes will be visible to itself. + To read data in their actual current state when running a transaction + at the SERIALIZABLE isolation level, you have to execute the LOCK TABLE + statement before executing any DML statement. A serializable + transaction's view of data will be frozen when its first DML statement + begins. @@ -341,7 +346,7 @@ ERROR name: Table does not exist. - To continue with the deadlock (when two transaction wait for one another) + To continue with the deadlock (when two transactions wait for one another) issue raised above, you should follow two general rules to prevent deadlock conditions: @@ -364,8 +369,8 @@ ERROR name: Table does not exist. Transactions should acquire two conflicting lock modes only if - one of them is self-conflicting (i.e., may be held by one - transaction at time only). If multiple lock modes are involved, + one of them is self-conflicting (i.e., may be held by only one + transaction at a time). If multiple lock modes are involved, then transactions should always acquire the most restrictive mode first. @@ -399,19 +404,17 @@ ERROR name: Table does not exist. - LOCK is a PostgreSQL - language extension. + LOCK ... IN ACCESS SHARE MODE requires SELECT + privileges on the target table. All other forms of LOCK + require UPDATE and/or DELETE privileges. - Except for ACCESS SHARE, ACCESS EXCLUSIVE, and SHARE UPDATE EXCLUSIVE lock - modes, the PostgreSQL lock modes and the - LOCK TABLE syntax are compatible with those - present in Oracle. - - - - LOCK works only inside transactions. + LOCK is useful only inside a transaction block + (BEGIN...COMMIT), since the lock is dropped + as soon as the transaction ends. A LOCK command appearing + outside any transaction block forms a self-contained transaction, so the + lock will be dropped as soon as it is obtained. @@ -471,6 +474,13 @@ COMMIT WORK; concurrency levels on transactions. We support that too; see for details. + + + Except for ACCESS SHARE, ACCESS EXCLUSIVE, and SHARE UPDATE EXCLUSIVE lock + modes, the PostgreSQL lock modes and the + LOCK TABLE syntax are compatible with those + present in Oracle(TM). +