diff --git a/doc/src/sgml/ref/release_savepoint.sgml b/doc/src/sgml/ref/release_savepoint.sgml
index daf8eb9a43..1f849a356f 100644
--- a/doc/src/sgml/ref/release_savepoint.sgml
+++ b/doc/src/sgml/ref/release_savepoint.sgml
@@ -39,18 +39,19 @@ RELEASE [ SAVEPOINT ] <replaceable>savepoint_name</replaceable>
   </para>
 
   <para>
-   Destroying a savepoint makes it unavailable as a rollback point,
-   but it has no other user visible behavior.  It does not undo the
-   effects of commands executed after the savepoint was established.
-   (To do that, see <xref linkend="sql-rollback-to"/>.)
-   Destroying a savepoint when
-   it is no longer needed allows the system to reclaim some resources
-   earlier than transaction end.
+   The term "destroy" is taken from the SQL Standard. The full meaning is to
+   subcommit the changes made within the current subtransaction, remove the
+   savepoint as a future rollback target and to return to the context of the
+   parent transaction or subtransaction. Thus the user should note that further
+   changes made after <command>RELEASE SAVEPOINT</command> will be in the
+   same transaction, and have the same xid, as changes made before the
+   named savepoint was created.
   </para>
 
   <para>
    <command>RELEASE SAVEPOINT</command> also destroys all savepoints that were
-   established after the named savepoint was established.
+   established after the named savepoint was established. This means that any
+   subtransactions of the named savepoint will also be subcommitted.
   </para>
  </refsect1>
 
@@ -78,7 +79,7 @@ RELEASE [ SAVEPOINT ] <replaceable>savepoint_name</replaceable>
 
   <para>
    It is not possible to release a savepoint when the transaction is in
-   an aborted state.
+   an aborted state, to do that use <xref linkend="sql-rollback-to"/>.
   </para>
 
   <para>
@@ -104,6 +105,37 @@ COMMIT;
 </programlisting>
    The above transaction will insert both 3 and 4.
   </para>
+
+  <para>
+   A more complex example with multiple nested subtransactions:
+<programlisting>
+BEGIN;
+    INSERT INTO table1 VALUES (1);
+    SAVEPOINT sp1;
+    INSERT INTO table1 VALUES (2);
+    SAVEPOINT sp2;
+    INSERT INTO table1 VALUES (3);
+    RELEASE SAVEPOINT sp2;
+    INSERT INTO table1 VALUES (4))); --error
+</programlisting>
+   In this example, the application requests subcommit of value 3, by
+   requesting that sp2 is released. However, releasing savepoint sp2
+   returns the transaction context to savep1, so when the statement
+   attempting to insert value 4 throws an error, the changes for
+   values 2, 3 and 4 are lost because values 2 and 4 are in the same,
+   now-aborted subtransaction, and value 3 is in a subcommitted
+   transaction that is also now aborted. The application can now
+   choose one of these two commands, since all other commands will be
+   ignored with a warning:
+<programlisting>
+   ROLLBACK;
+   ROLLBACK TO SAVEPOINT sp1;
+</programlisting>
+   Choosing <command>ROLLBACK</command> will abort everything, including
+   value 1, whereas <command>ROLLBACK TO SAVEPOINT</command> will retain
+   value 1 and allow the transaction to continue.
+  </para>
+
  </refsect1>
 
  <refsect1>