Last-minute updates for release notes.

The set of functions that need parallel-safety adjustments isn't the
same in 9.6 as 10, so I shouldn't have blindly back-patched that list.
Adjust as needed.  Also, provide examples of the commands to issue.

doc/src/sgml/release-10.sgml

@@ -106,10 +106,12 @@ Branch: REL9_3_STABLE [485857d44] 2018-03-30 18:14:51 -0400
       installations will continue to contain the incorrect markings.
       Practical use of these functions seems to pose little hazard, but in
       case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
-      option is to <application>pg_upgrade</application> the database to a
+      boolean, text) VOLATILE</literal>.  (Note that that will need to be
-      version containing the corrected initial data.
+      done in each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>
 
@@ -146,10 +148,12 @@ Branch: REL9_6_STABLE [91d82317d] 2018-03-30 18:14:51 -0400
       incorrect markings.  Practical use of these functions seems to pose
       little hazard unless <varname>force_parallel_mode</varname> is turned
       on.  In case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass)
-      option is to <application>pg_upgrade</application> the database to a
+      PARALLEL UNSAFE</literal>.  (Note that that will need to be done in
-      version containing the corrected initial data.
+      each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>
 

doc/src/sgml/release-9.3.sgml

@@ -59,10 +59,12 @@
       installations will continue to contain the incorrect markings.
       Practical use of these functions seems to pose little hazard, but in
       case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
-      option is to <application>pg_upgrade</application> the database to a
+      boolean, text) VOLATILE</literal>.  (Note that that will need to be
-      version containing the corrected initial data.
+      done in each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>
 

doc/src/sgml/release-9.4.sgml

@@ -59,10 +59,12 @@
       installations will continue to contain the incorrect markings.
       Practical use of these functions seems to pose little hazard, but in
       case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
-      option is to <application>pg_upgrade</application> the database to a
+      boolean, text) VOLATILE</literal>.  (Note that that will need to be
-      version containing the corrected initial data.
+      done in each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>
 

doc/src/sgml/release-9.5.sgml

@@ -59,10 +59,12 @@
       installations will continue to contain the incorrect markings.
       Practical use of these functions seems to pose little hazard, but in
       case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
-      option is to <application>pg_upgrade</application> the database to a
+      boolean, text) VOLATILE</literal>.  (Note that that will need to be
-      version containing the corrected initial data.
+      done in each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>
 

doc/src/sgml/release-9.6.sgml

@@ -91,10 +91,12 @@
       installations will continue to contain the incorrect markings.
       Practical use of these functions seems to pose little hazard, but in
       case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.query_to_xml(text, boolean,
-      option is to <application>pg_upgrade</application> the database to a
+      boolean, text) VOLATILE</literal>.  (Note that that will need to be
-      version containing the corrected initial data.
+      done in each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>
 
@@ -107,15 +109,12 @@
      <para>
       The functions
       <function>brin_summarize_new_values</function>,
-      <function>brin_summarize_range</function>,
-      <function>brin_desummarize_range</function>,
       <function>gin_clean_pending_list</function>,
       <function>cursor_to_xml</function>,
       <function>cursor_to_xmlschema</function>,
       <function>ts_rewrite</function>,
-      <function>ts_stat</function>,
+      <function>ts_stat</function>, and
-      <function>binary_upgrade_create_empty_extension</function>, and
+      <function>binary_upgrade_create_empty_extension</function>
-      <function>pg_import_system_collations</function>
       should be marked parallel-unsafe; some because they perform database
       modifications directly, and others because they execute user-supplied
       queries that might do so.  They were marked parallel-restricted
@@ -125,10 +124,12 @@
       incorrect markings.  Practical use of these functions seems to pose
       little hazard unless <varname>force_parallel_mode</varname> is turned
       on.  In case of trouble, it can be fixed by manually updating these
-      functions' <structname>pg_proc</structname> entries.  (Note that that
+      functions' <structname>pg_proc</structname> entries, for example
-      will need to be done in each database of the installation.)  Another
+      <literal>ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass)
-      option is to <application>pg_upgrade</application> the database to a
+      PARALLEL UNSAFE</literal>.  (Note that that will need to be done in
-      version containing the corrected initial data.
+      each database of the installation.)  Another option is
+      to <application>pg_upgrade</application> the database to a version
+      containing the corrected initial data.
      </para>
     </listitem>