Initial release notes created for 9.6
I've pushed a first cut at release notes for 9.6. There's a good deal
of work to do yet:
* The section about parallel query could probably stand to be fleshed out,
but I'm unsure what to say. Somebody who's worked on that should provide
some text.
* 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.
* As is somewhat customary for early drafts of the notes, I've made no
attempt to call out which are the most significant changes. I've not
tried to isolate the non-backwards-compatible items, either.
Please review and comment before Monday, if you can.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/05/2016 10:32 AM, Tom Lane wrote:
I've pushed a first cut at release notes for 9.6. There's a good deal
of work to do yet:* The section about parallel query could probably stand to be fleshed out,
but I'm unsure what to say. Somebody who's worked on that should provide
some text.* 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.* As is somewhat customary for early drafts of the notes, I've made no
attempt to call out which are the most significant changes. I've not
tried to isolate the non-backwards-compatible items, either.Please review and comment before Monday, if you can.
Just for the cheap seats, I assume they are pushed to git?
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
On 05/05/2016 10:32 AM, Tom Lane wrote:
I've pushed a first cut at release notes for 9.6. There's a good deal
of work to do yet:
Just for the cheap seats, I assume they are pushed to git?
Should appear at
http://www.postgresql.org/docs/devel/static/release-9-6.html
after awhile, though it looks like it'll be about three hours before
guaibasaurus gets around to it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 5, 2016 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I've pushed a first cut at release notes for 9.6. There's a good deal
of work to do yet:* The section about parallel query could probably stand to be fleshed out,
but I'm unsure what to say. Somebody who's worked on that should provide
some text.* 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.* As is somewhat customary for early drafts of the notes, I've made no
attempt to call out which are the most significant changes. I've not
tried to isolate the non-backwards-compatible items, either.Please review and comment before Monday, if you can.
As far as the parallel query stuff goes,
https://wiki.postgresql.org/wiki/Parallel_Query is a useful overview
of current restrictions which I'm still hoping to get incorporated
into the SGML documentation. I suggest revising the text to something
like this:
===
With 9.6, <productname>PostgreSQL</> introduces initial support for
parallel execution of large queries. Only strictly read-only queries
where the driving table is accessed via a sequential scan can be
parallelized. Hash joins and nested loops can be performed in
parallel, as can aggregation for supported aggregates. Much remains
to be done, but this is already a useful set of features.
===
If we put the documentation from that wiki page into the docs
someplace, then we could add a sentence "For an overview of the
current capabilities of parallel query, including relevant
restrictions, see <splat>."
I'd probably mention David Rowley as a third author on parallel query.
It's true that the great bulk of the development work and design over
the last few years was done by Amit and I, but parallel aggregate
resulted in several large patches that were entirely written by David.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 5, 2016 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
* As is somewhat customary for early drafts of the notes, I've made no
attempt to call out which are the most significant changes. I've not
tried to isolate the non-backwards-compatible items, either.
There was quite a bit of discussion of this on pgsql-advocacy, and the
press release we're going to put out surely must say something. It
wouldn't hurt if the release notes at least somewhat matched that. I
thought this was a decent list:
/messages/by-id/571FB941.3020007@commandprompt.com
Although "phrase search" seems a bit less important to me than the
rest of those. There's also a good, somewhat-more-inclusive list of
the big stuff here:
https://en.wikipedia.org/wiki/PostgreSQL#Upcoming_features
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 5, 2016 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please review and comment before Monday, if you can.
Overall, I think this looks pretty great. Thanks for pulling it
together so quickly. Various nitpicky comments below.
+ <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>I think this should be rephrased so as to make it clear that we only
do this when there is contention.
+<!--
+2016-04-10 [008608b9d] Avoid the use of a separate spinlock to protect a LWLock
+-->
+ <para>
+ Use atomic operations, rather than a spinlock, to protect an LWLock's
+ wait queue (Andres Freund)
+ </para>
+ </listitem>
+
+ <listitem>This was basically an attempt to cure a defect in 48354581a and could
perhaps be lumped under that item.
+ <para>
+ Force backends to exit if the postmaster dies
+ (Rajeev Rastogi and Robert Haas)
+ </para>
+Separator between names should probably be a comma rather than "and".
+ <para>
+ Ensure that trigonometric functions handle infinity and NaN inputs per
+ spec (Dean Rasheed)
+ </para>"per spec" is pretty vague. What spec? And how about spelling out
"specification"?
+ <para>
+ An example usage is <literal>CHECK(num_nonnulls(a,b,c) = 1)</> which
+ asserts that exactly one of a,b,c isn't NULL. These functions can
+ also be pressed into service to count the number of null or nonnull
+ elements in an array.
+ </para>"pressed into service"? If it's a hack, let's not mention it at all.
If it's not a hack, let's just say the functions can do that, plain
and simple.
+ <para>
+ This function converts strings like those produced
+ by <function>pg_size_pretty()</> into sizes in bytes. An example
+ usage is <literal>WHERE pg_total_relation_size(oid) >
+ pg_size_bytes('10 GB')</>.
+ </para>I would be inclined to expend a few more bytes to turn that into a
complete SQL query, like "SELECT oid::regclass FROM pg_class
WHERE...".
+ <para>
+ In <function>pg_size_pretty()</>, format negative numbers similarly to
+ positive ones (Adrian Vondendriesch)
+ </para>Maybe add: "Previously, the suffix for a negative number was always
'bytes', never 'kB', 'MB', 'GB', or 'TB'". Or something like that.
+ <para>
+ Add an optional <replaceable>missing_ok</> argument to
+ the <function>current_setting()</> function (David Christensen)
+ </para>Adjust text to clarify that it suppresses the error for a nonexisting setting?
+ <para>
+ Improve error reporting during <application>initdb</>'s post-bootstrap
+ phase, by not reporting the entire input file as the <quote>failing
+ query</> (Tom Lane)
+ </para>This reads oddly to me How about "When initdb fails during the
post-bootstrap phase, report the failing query rather than the
entirety of the file that contained it"?
+ <para>
+ Consider performing sorts on the remote server (Ashutosh Bapat)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+2016-02-09 [e4106b252] postgres_fdw: Push down joins to remote servers.
+2016-03-09 [aa09cd242] postgres_fdw: Consider foreign joining and foreign sorti
+-->
+ <para>
+ Push down joins to the remote server when possible (Shigeru Hanada,
+ Ashutosh Bapat)
+ </para>I think these could be worded the same way. Like maybe "Consider
performing sorts on the remote server" and "Consider performing joins
on the remote server".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016-05-05 16:25:38 -0400, Robert Haas wrote:
On Thu, May 5, 2016 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please review and comment before Monday, if you can.
Overall, I think this looks pretty great. Thanks for pulling it
together so quickly.
+1
+<!-- +2016-04-10 [008608b9d] Avoid the use of a separate spinlock to protect a LWLock +--> + <para> + Use atomic operations, rather than a spinlock, to protect an LWLock's + wait queue (Andres Freund) + </para> + </listitem> + + <listitem>This was basically an attempt to cure a defect in 48354581a and could
perhaps be lumped under that item.
It's also an independent performance improvement (sadly), and has the
potential for issues; so there's *some* benefits on keeping this as its
own entry.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
On 2016-05-05 16:25:38 -0400, Robert Haas wrote:
This was basically an attempt to cure a defect in 48354581a and could
perhaps be lumped under that item.
It's also an independent performance improvement (sadly), and has the
potential for issues; so there's *some* benefits on keeping this as its
own entry.
I left that as-is, but otherwise adopted Robert's suggestions.
Thanks for the comments!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 6, 2016 at 7:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.de> writes:
On 2016-05-05 16:25:38 -0400, Robert Haas wrote:
This was basically an attempt to cure a defect in 48354581a and could
perhaps be lumped under that item.It's also an independent performance improvement (sadly), and has the
potential for issues; so there's *some* benefits on keeping this as its
own entry.I left that as-is, but otherwise adopted Robert's suggestions.
Thanks for the comments!
Are you not adding VS2015 support in those notes? Petr Jelinek is a
co-author btw, he's missing from the credits in 0fb54de.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
Are you not adding VS2015 support in those notes?
Hmm, I had decided that wasn't worth listing, but now I can't think
why :-(. Will add it.
Petr Jelinek is a
co-author btw, he's missing from the credits in 0fb54de.
OK, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5/5/16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please review and comment before Monday, if you can.
regards, tom lane
1. "YUriy Zhuravlev" should be "Yury Zhuravlev"
Previously[1]/messages/by-id/2723429.ZaCixaFn1x@dinodell he had the first version in his signature, but I guess
it was misconfiguring, now[2]/messages/by-id/dd701b62-008d-4048-882e-20df0e4b59a2@postgrespro.ru hi has second version.
2. I'd add Dean Rasheed as co-author to "Add pg_size_bytes()" since
being a committer he made more than cosmetic changes[3]/messages/by-id/CAEZATCXHZ5gGFrfcF9_yw5h6WDxr68qdFiWhvMgFR3ascnQCag@mail.gmail.com -- Best regards, Vitaly Burovoy but he was
humble enough not to mention himself in the commit message.
[1]: /messages/by-id/2723429.ZaCixaFn1x@dinodell
[2]: /messages/by-id/dd701b62-008d-4048-882e-20df0e4b59a2@postgrespro.ru
[3]: /messages/by-id/CAEZATCXHZ5gGFrfcF9_yw5h6WDxr68qdFiWhvMgFR3ascnQCag@mail.gmail.com -- Best regards, Vitaly Burovoy
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Vitaly Burovoy <vitaly.burovoy@gmail.com> writes:
1. "YUriy Zhuravlev" should be "Yury Zhuravlev"
Previously[1] he had the first version in his signature, but I guess
it was misconfiguring, now[2] hi has second version.
Ah. Now that I look, I see we've got three different ASCII-izations
of his name in the notes, none of them right :-(
2. I'd add Dean Rasheed as co-author to "Add pg_size_bytes()" since
being a committer he made more than cosmetic changes[3] but he was
humble enough not to mention himself in the commit message.
OK.
Thanks for the info!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
Are you not adding VS2015 support in those notes?
Hmm, I had decided that wasn't worth listing, but now I can't think
why :-(. Will add it.
Oh, now I see why it's not here: it was back-patched into 9.5, so it
will not be a new feature in 9.6.0. It will be listed in the 9.5.3
release notes, instead.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 5, 2016 at 5:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hmm, I had decided that wasn't worth listing, but now I can't think
why :-(. Will add it.Oh, now I see why it's not here: it was back-patched into 9.5, so it
will not be a new feature in 9.6.0. It will be listed in the 9.5.3
release notes, instead.
I was really hoping that the OpenSSL bugfix patch would receive the
same treatment (commit 7c7d4fddab82dc756d8caa67b1b31fcdde355aab).
Should I take its inclusion here in the 9.6 release notes as
portending a backpatch never happening?
There seems to be a lack of urgency about it, and given that it's
moderately complicated, that tends to mean it will keep getting put
off. I did notice that you have an sgml comment about it, but the
wording isn't optimistic.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 6, 2016 at 2:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I've pushed a first cut at release notes for 9.6. There's a good deal
of work to do yet:* The section about parallel query could probably stand to be fleshed out,
but I'm unsure what to say. Somebody who's worked on that should provide
some text.* 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.* As is somewhat customary for early drafts of the notes, I've made no
attempt to call out which are the most significant changes. I've not
tried to isolate the non-backwards-compatible items, either.Please review and comment before Monday, if you can.
+ Avoid re-vacuuming pages containing only frozen tuples
+ (Masahiko Sawada, Robert Haas)+ Support synchronous replication with multiple synchronous standby
+ servers, not just one (Sawada Masahiko, Beena Emerson, Michael
+ Paquier, Fujii Masao, Kyotaro Horiguchi)Very minor comment but I'd like to unify my name to First Last (i.g.,
Masahiko Sawada).
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
On Thu, May 5, 2016 at 5:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Oh, now I see why it's not here: it was back-patched into 9.5, so it
will not be a new feature in 9.6.0. It will be listed in the 9.5.3
release notes, instead.
I was really hoping that the OpenSSL bugfix patch would receive the
same treatment (commit 7c7d4fddab82dc756d8caa67b1b31fcdde355aab).
Should I take its inclusion here in the 9.6 release notes as
portending a backpatch never happening?
No, it just means that hasn't happened yet.
There seems to be a lack of urgency about it,
Perhaps, or maybe it's just a lack of cycles. I certainly haven't
had any time to think about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> writes:
Very minor comment but I'd like to unify my name to First Last (i.g.,
Masahiko Sawada).
Will fix, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 5, 2016 at 10:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please review and comment before Monday, if you can.
I think that there could stand to be some consolidation among the
items that I authored.
Firstly, there's the abbreviated key stuff. The 9.5 notes described
the abbreviated keys feature as follows:
"""
Improve the speed of sorting of varchar, text, and numeric fields via
"abbreviated" keys (Peter Geoghegan, Andrew Gierth, Robert Haas)
"""
Users only cared that there was a nice optimization added to sorting
that affects only the types listed. The main point of this
optimization is that most comparisons can elide a memory access,
anyway. So, I suggest that you consolidate the two new 9.6 items as
follows:
"""
Improve the speed of sorting of UUID, bytea, and char(n) fields via
"abbreviated" keys.
Support for the optimization has also been added to the non-default
operator classes text_pattern_ops, varchar_pattern_ops, and
bpchar_pattern_ops, which support B-tree indexes on the types text,
varchar, and char respectively.
"""
So, that's just one final item instead of two.
Also, I personally don't really think of these two as separate items,
even though technically they're independently useful:
"""
Improve sorting performance by using quicksort, not replacement
selection, within steps of an external sort (Peter Geoghegan)
This behavior can be adjusted via the new configuration parameter
replacement_sort_tuples.
"""
and:
"""
Improve memory management for external sorts (Peter Geoghegan)
"""
If it were up to me, I'd consolidate the two, and provide a
higher-level description. I'd probably say something about CPU cache
efficiency, and how the distinction between external sorts and
internal sorts has been significantly softened. I'd also mention that
the new approach can make better use of larger work_mem settings, and
great temp_tablespaces I/O capacity, which Bruce agreed warranted
notice in the release notes [1]/messages/by-id/20160430234133.GH556@momjian.us -- Peter Geoghegan.
I can make a suggestion here, too, if you're interested.
[1]: /messages/by-id/20160430234133.GH556@momjian.us -- Peter Geoghegan
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
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).
I hadn't focused on this before, but wal_writer_flush_after is new in 9.6.
I think the right thing to do here is to remove the separate entry for
7975c5e0a and just treat it as part of this group.
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?
Right, I was thinking about syscalls. But given that this only happens
under contention, maybe best to just take that part out.
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.
I doubt it's necessary to explain that in the release notes...
Hm, I guess we need a warning about reindexing such indexes after a pg_upgrade somwhere?
See discussion with Noah yesterday.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
