First-draft release notes for Postgres 9.6.

These are just of beta quality, but we're only at beta ... the section
about parallel query, in particular, could doubtless use more work.

doc/src/sgml/catalogs.sgml

@@ -7575,8 +7575,8 @@
    be used by software packages that want to interface to
    <productname>PostgreSQL</> to facilitate finding the required header
    files and libraries. It provides the same basic information as the
-   <xref linkend="app-pgconfig"> <productname>PostgreSQL</> Client
-   Application.
+   <xref linkend="app-pgconfig"> <productname>PostgreSQL</> client
+   application.
   </para>
 
   <table>

doc/src/sgml/config.sgml

@@ -2012,7 +2012,7 @@ include_dir 'conf.d'
          number of workers may not actually be available at runtime.  If this
          occurs, the plan will run with fewer workers than expected, which may
          be inefficient.  The default value is 2.  Setting this value to 0
-         disables parallel query.
+         disables parallel query execution.
         </para>
        </listitem>
       </varlistentry>
@@ -3657,32 +3657,32 @@ include_dir 'conf.d'
       </listitem>
      </varlistentry>
 
-     <varlistentry id="parallel-tuple-cost" xreflabel="parallel_tuple_cost">
-      <term><varname>parallel_tuple_cost</varname> (<type>floating point</type>)
+     <varlistentry id="guc-parallel-setup-cost" xreflabel="parallel_setup_cost">
+      <term><varname>parallel_setup_cost</varname> (<type>floating point</type>)
       <indexterm>
-       <primary><varname>parallel_tuple_cost</> configuration parameter</primary>
+       <primary><varname>parallel_setup_cost</> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
-        Sets the planner's estimate of the cost of transferring a tuple
-        from a parallel worker process to another process.
-        The default is 0.1.
+        Sets the planner's estimate of the cost of launching parallel worker
+        processes.
+        The default is 1000.
        </para>
       </listitem>
      </varlistentry>
 
-     <varlistentry id="parallel-setup-cost" xreflabel="parallel_setup_cost">
-      <term><varname>parallel_setup_cost</varname> (<type>floating point</type>)
+     <varlistentry id="guc-parallel-tuple-cost" xreflabel="parallel_tuple_cost">
+      <term><varname>parallel_tuple_cost</varname> (<type>floating point</type>)
       <indexterm>
-       <primary><varname>parallel_setup_cost</> configuration parameter</primary>
+       <primary><varname>parallel_tuple_cost</> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
-        Sets the planner's estimate of the cost of launching parallel worker
-        processes.
-        The default is 1000.
+        Sets the planner's estimate of the cost of transferring one tuple
+        from a parallel worker process to another process.
+        The default is 0.1.
        </para>
       </listitem>
      </varlistentry>
@@ -4048,8 +4048,8 @@ SELECT * FROM parent WHERE key = 2400;
         <literal>off</> (use parallel mode only when it is expected to improve
         performance), <literal>on</> (force parallel query for all queries
         for which it is thought to be safe), and <literal>regress</> (like
-        on, but with additional behavior changes to facilitate automated
-        regression testing).
+        <literal>on</>, but with additional behavior changes as explained
+        below).
        </para>
 
        <para>
@@ -4067,14 +4067,14 @@ SELECT * FROM parent WHERE key = 2400;
 
        <para>
         Setting this value to <literal>regress</> has all of the same effects
-        as setting it to <literal>on</> plus some additional effect that are
+        as setting it to <literal>on</> plus some additional effects that are
         intended to facilitate automated regression testing.  Normally,
-        messages from a parallel worker are prefixed with a context line,
-        but a setting of <literal>regress</> suppresses this to guarantee
-        reproducible results.  Also, the <literal>Gather</> nodes added to
-        plans by this setting are hidden from the <literal>EXPLAIN</> output
-        so that the output matches what would be obtained if this setting
-        were turned <literal>off</>.
+        messages from a parallel worker include a context line indicating that,
+        but a setting of <literal>regress</> suppresses this line so that the
+        output is the same as in non-parallel execution.  Also,
+        the <literal>Gather</> nodes added to plans by this setting are hidden
+        in <literal>EXPLAIN</> output so that the output matches what
+        would be obtained if this setting were turned <literal>off</>.
        </para>
       </listitem>
      </varlistentry>

doc/src/sgml/filelist.sgml

@@ -167,6 +167,7 @@
 <!ENTITY sourcerepo SYSTEM "sourcerepo.sgml">
 
 <!ENTITY release    SYSTEM "release.sgml">
+<!ENTITY release-9.6    SYSTEM "release-9.6.sgml">
 <!ENTITY release-9.5    SYSTEM "release-9.5.sgml">
 <!ENTITY release-9.4    SYSTEM "release-9.4.sgml">
 <!ENTITY release-9.3    SYSTEM "release-9.3.sgml">

doc/src/sgml/monitoring.sgml

@@ -2524,7 +2524,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
    view.
   </para>
 
-  <table id="pg-stat-progress-vacuum" xreflabel="pg_stat_progress_vacuum">
+  <table id="pg-stat-progress-vacuum-view" xreflabel="pg_stat_progress_vacuum">
    <title><structname>pg_stat_progress_vacuum</structname> View</title>
    <tgroup cols="3">
     <thead>

doc/src/sgml/release.sgml

@@ -73,6 +73,7 @@ For new features, add links to the documentation sections.
   The reason for splitting the release notes this way is so that appropriate
   subsets can easily be copied into back branches.
 -->
+&release-9.6;
 &release-9.5;
 &release-9.4;
 &release-9.3;