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  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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers