postgres.git / summary / log / commit / refs

commit    6e727a13cbc189e5974c3e8f6fa3eff9f87d1417
Author:   Bruce Momjian <bruce@momjian.us>
Date:     Tue Mar 31 21:27:32 2020 +0000
First released in: 13.0, 9.5.22, 9.6.18, 10.13, 11.8, 12.3

    doc:  clarify when row-level locks are released
    
    They are released just like table-level locks.  Also clean up wording.
    
    Reported-by: me@sillymon.ch
    
    Discussion: https://postgr.es/m/158074944048.1095.4309647363871637715@wrigleys.postgresql.org
    
    Backpatch-through: 9.5


 doc/src/sgml/mvcc.sgml | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 306def4a15a..1788e0f1e47 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1035,9 +1035,9 @@ ERROR:  could not serialize access due to read/write dependencies among transact
      </tip>
 
    <para>
-    Once acquired, a lock is normally held till end of transaction.  But if a
+    Once acquired, a lock is normally held until the end of the 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
+    immediately if the savepoint is rolled back.  This is consistent with
     the principle that <command>ROLLBACK</> cancels all effects of the
     commands since the savepoint.  The same holds for locks acquired within a
     <application>PL/pgSQL</> exception block: an error escape from the block
@@ -1174,7 +1174,10 @@ ERROR:  could not serialize access due to read/write dependencies among transact
      conflicting locks on the same row, even in different subtransactions;
      but other than that, two transactions can never hold conflicting locks
      on the same row.  Row-level locks do not affect data querying; they
-     block only <emphasis>writers and lockers</emphasis> to the same row.
+     block only <emphasis>writers and lockers</emphasis> to the same
+     row.  Row-level locks are released at transaction end or during
+     savepoint rollback, just like table-level locks.
+
     </para>
 
      <variablelist>


[parent: ce5d82f2d0fd]