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