doc: clarify when row-level locks are released

They are released just like table-level locks.  Also clean up wording.
(Uses wording "rolled back to".)

Reported-by: me@sillymon.ch

Discussion: https://postgr.es/m/158074944048.1095.4309647363871637715@wrigleys.postgresql.org

Backpatch-through: 9.5
This commit is contained in:
Bruce Momjian 2020-03-31 17:57:44 -04:00
parent 7dbe290da4
commit 046fd4f364
1 changed files with 5 additions and 2 deletions

View File

@ -1039,7 +1039,7 @@ ERROR: could not serialize access due to read/write dependencies among transact
</tip> </tip>
<para> <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 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 to. This is consistent with
the principle that <command>ROLLBACK</command> cancels all effects of the the principle that <command>ROLLBACK</command> cancels all effects of the
@ -1178,7 +1178,10 @@ ERROR: could not serialize access due to read/write dependencies among transact
conflicting locks on the same row, even in different subtransactions; conflicting locks on the same row, even in different subtransactions;
but other than that, two transactions can never hold conflicting locks but other than that, two transactions can never hold conflicting locks
on the same row. Row-level locks do not affect data querying; they 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> </para>
<variablelist> <variablelist>