Re: Initial release notes created for 9.6

Hi,

On 2016-05-05 13:32:55 -0400, Tom Lane wrote:
> * Bruce usually likes to sprinkle the notes with a whole lot of links
> to the main docs.  I've only bothered with links for new GUCs and system
> views.

I guess it'd be worthwhile to add a links for new SQL functions as well.


> Please review and comment before Monday, if you can.

Some minor comments:

+<!--
+2016-03-10 [428b1d6b2] Allow to trigger kernel writeback after a configurable n
+2016-04-13 [fa11a09fe] Fix assorted portability issues with using msync() for d
+2016-04-24 [8f91d87d4] Fix documentation & config inconsistencies around 428b1d
+2016-04-26 [72a98a639] Don't open formally non-existent segments in _mdfd_getse
+-->
+       <para>
+        Where feasible, trigger kernel writeback after a configurable number
+        of writes, to prevent accumulation of dirty data in kernel disk
+        buffers (Fabien Coelho, Andres Freund)
+       </para>
+
+       <para>
+        The new configuration parameters
+        <xref linkend="guc-backend-flush-after">,
+        <xref linkend="guc-bgwriter-flush-after">,
+        <xref linkend="guc-checkpoint-flush-after">, and
+        <xref linkend="guc-wal-writer-flush-after"> control this behavior.
+       </para>
+      </listitem>

wal-writer-flush-after doesn't really fit into this section, it wasn't
affected by any of the above commits, and the change in 9.6 is to make
it *less* aggressive in flushing (as you listed in a separate entry).

+<!--
+2016-04-08 [719c84c1b] Extend relations multiple blocks at a time to improve sc
+-->
+       <para>
+        Extend relations multiple blocks at a time (Dilip Kumar)
+       </para>
+
+       <para>
+        This reduces kernel traffic, and improves scalability when multiple
+        processes are inserting into the same relation.
+       </para>
+      </listitem>

Hm. Kernel traffic is maybe a bit hard to understand (guess you're
referring to the number of syscalls)? Isn't that also affecting actual
IO? But mostly it's about our own locking around relation extension?

+<!--
+2015-12-15 [6150a1b08] Move buffer I/O and content LWLocks out of the main tran
+-->
+       <para>
+        Improve performance by moving buffer content locks into the buffer
+        descriptors (Andres Freund, Simon Riggs)
+       </para>
+      </listitem>

An important benefit here is that after that patch we can increase
the padding of the locks remaining lwlocks; which we previously
avoided out of memory usage concerns.


+<!--
+2016-02-17 [a5c43b886] Add new system view, pg_config
+-->
+       <para>
+        Add <link linkend="view-pg-config"><structname>pg_config</></link>
+        system view to expose the same information available from
+        the <application>pg_config</> utility (Joe Conway)
+       </para>
+      </listitem>

Hm. Rereading this I'm wondering whether pg_config isn't going to be
confused with pg_settings all the time.


+      <listitem>
+<!--
+XXX this is pending backpatch, may need to remove
+2016-04-26 [c6ff84b06] Emit invalidations to standby for transactions without x
+-->
+       <para>
+        Ensure that invalidation messages are recorded in WAL even when
+        issued by a transaction that has no XID assigned (Andres Freund)
+       </para>
+
+       <para>
+        This fixes some corner cases in which transactions on standby
+        servers failed to notice changes such as new indexes.
+       </para>
+      </listitem>

FWIW, I'm getting more and more doubtful about backpatching this - the
risk of breaking people's setup seems a lot more severe than any of
the known symptoms - but will start that conversation in the relevant
thread.

+      <listitem>
+<!--
+2015-12-16 [f27a6b15e] Mark CHECK constraints declared NOT VALID valid if creat
+-->
+       <para>
+        If a <literal>CHECK</> constraint is declared <literal>NOT VALID</> in
+        a table creation command, automatically mark it valid (Amit Langote,
+        Amul Sul)
+       </para>
+
+       <para>
+        This matches the longstanding behavior of <literal>FOREIGN KEY</>
+        constraints.
+       </para>
+      </listitem>

Heh. I was about to say that NOT VALID for constraint is relatively
new, just to find out it's been introduced in 9.1...


+
+      <listitem>
+<!--
+2016-04-08 [293007898] Reserve the "pg_" namespace for roles
+-->
+       <para>
+        Treat role names beginning with <literal>pg_</> as reserved
+        (Stephen Frost)
+       </para>
+
+       <para>
+        User creation of such role names is now disallowed.  This prevents
+        conflicts with built-in roles created by <application>initdb</>.
+       </para>
+      </listitem>

Maybe we should mention that that's similar to restrictions around
naming schemas?


+      <listitem>
+<!--
+2016-03-29 [61d66c44f] Fix support of digits in email/hostnames.
+-->
+       <para>
+        Fix text search parser to allow leading digits in <literal>email</>
+        and <literal>host</> tokens (Artur Zakirov)
+       </para>
+
+       <para>
+        In most cases this will result in few changes in the parsing of text.
+        But if you have data where such addresses occur frequently, it may be
+        worth rebuilding dependent <type>tsvector</> columns and indexes, so
+        that addresses of this form will be found properly by text searches.
+       </para>
+      </listitem>

Hm, I guess we need a warning about reindexing such indexes after a pg_upgrade somwhere?


- Andres