Move description of general lock behaviour out of the "13.3.1. Table-level Locks section"

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