Обсуждение: 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

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.

"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?

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c311f7887376f7f3ce24c4c0dac4f9cb6ad3bee3

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

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

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:

http://www.postgresql.org/message-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

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

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

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

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

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

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] he had the first version in his signature, but I guess
it was misconfiguring, now[2] 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] but he was
humble enough not to mention himself in the commit message.

[1] http://www.postgresql.org/message-id/2723429.ZaCixaFn1x@dinodell
[2] http://www.postgresql.org/message-id/dd701b62-008d-4048-882e-20df0e4b59a2@postgrespro.ru
[3] http://www.postgresql.org/message-id/CAEZATCXHZ5gGFrfcF9_yw5h6WDxr68qdFiWhvMgFR3ascnQCag@mail.gmail.com
-- 
Best regards,
Vitaly Burovoy

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

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

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

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

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

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

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].

I can make a suggestion here, too, if you're interested.

[1] http://www.postgresql.org/message-id/20160430234133.GH556@momjian.us
-- 
Peter Geoghegan

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

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

Peter Geoghegan <pg@heroku.com> writes:
> I think that there could stand to be some consolidation among the
> items that I authored.

After thinking a bit, I merged all the abbreviated-keys stuff including
the ordered-set-aggregate item.  Let me know if that seems wrong.

> Also, I personally don't really think of these two as separate items,
> even though technically they're independently useful:

OK, also merged.

> 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].

Meh.  The release notes are not the place for that kind of detail,
mainly because nobody will look at old release notes when searching
for info.  Also, I saw that you already had a rather long discussion
about this associated with the replacement_sort_tuples GUC (which
*is* a reasonable place for it).  My intention in providing the link
was so people could consult that info easily --- but I added a few
more words to point out explicitly that there was more info there.
        regards, tom lane

On Thu, May 5, 2016 at 7:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@heroku.com> writes:
>> I think that there could stand to be some consolidation among the
>> items that I authored.
>
> After thinking a bit, I merged all the abbreviated-keys stuff including
> the ordered-set-aggregate item.  Let me know if that seems wrong.

I didn't imagine going so far as putting the ordered-set aggregate
item in there too, but I actually think that that's an improvement.

>> 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].
>
> Meh.  The release notes are not the place for that kind of detail,
> mainly because nobody will look at old release notes when searching
> for info.

I agree with this, but was concerned that better advice around sizing
work_mem in the documentation would not be accepted.

> Also, I saw that you already had a rather long discussion
> about this associated with the replacement_sort_tuples GUC (which
> *is* a reasonable place for it).  My intention in providing the link
> was so people could consult that info easily --- but I added a few
> more words to point out explicitly that there was more info there.

The documentation provides only a very weak endorsement of the idea
that increasing maintenance_work_mem improves the performance of
*anything*, and it only does so once (work_mem doesn't even get that
much). It's easy to fail to notice that as an expert.

I actually think of the 9.6 work on external sorting as fixing a
problem peculiar to one particular consumer of work_mem as much as
anything else (the problem of weird CPU cache sensitivity). So, my
concern is fairly high-level. I want to communicate two ideas to
users:

1. Consider that your previous experiences with sizing work_mem might
be made obsolete by 9.6. You should be able to safely increase
work_mem with the expectation that doing so will more or less improve
performance across the board, or at least not hurt things. There are
some caveats, of course, but they're fairly limited, and even obvious
(e.g., don't let Postgres do a significant amount of swapping). We
don't need to equivocate, which ISTM is what we did when discussing
these settings before now.

If you think that's unfair, consider how terse the docs are when
discussing sizing work_mem compared to settings like commit_delay and
effective_io_concurrency.

2. A fast temp_tablespaces setting becomes more useful, particularly
when adding more memory stops helping.

I'm not sure that this even needs to be made about the external
sorting stuff. I'm not attached to communicating this to users in any
particular way.

-- 
Peter Geoghegan

Andres Freund wrote:

> On 2016-05-05 13:32:55 -0400, Tom Lane wrote:

> +<!--
> +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.

Hmm, yeah, that's a good point ...

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, May 5, 2016 at 10: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:

Thanks for assembling the notes.

This item:

"Avoid some spurious waits for AccessExclusiveLocks in hot-standby queries"

Should be something like

Avoid some unnecessary cancellations of hot-standy queries due to
AccessExclusiveLocks replay.

It was the cancellations, not the waits, which were spurious.

Cheers,

Jeff

* 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:

+<!--
+2016-04-08 [35e2e357c] Add authentication parameters compat_realm and 
upn_usena
+-->
+       <para>
+        Add new SSPI authentication parameters <varname>compat_realm</>
+        and <varname>upn_usename</>, to make it possible to make SSPI
+        work more like GSSAPI (Christian Ullrich)
+       </para>

It is upn_username, not usename. Typo in the commit message.

"Make SSPI work more like GSSAPI" reads like it changed authentication 
behavior in some fundamental way, and as if SSPI did not work like 
GSSAPI without it. The difference in behavior of include_realm between 
GSSAPI and SSPI is not caused by SSPI, but is an implementation detail 
on our end.

I suggest writing "use the Kerberos realm name for authentication 
instead of the NetBIOS name" either in place of the existing description 
or together with it.

Thanks,

-- 
Christian

Jeff Janes <jeff.janes@gmail.com> writes:
> This item:

> "Avoid some spurious waits for AccessExclusiveLocks in hot-standby queries"

> Should be something like

> Avoid some unnecessary cancellations of hot-standy queries due to
> AccessExclusiveLocks replay.

> It was the cancellations, not the waits, which were spurious.

OK, changing to
      <para>       Avoid some unnecessary cancellations of hot-standby queries during       replay of actions that take
AccessExclusiveLocks(Jeff Janes)      </para>
 
        regards, tom lane

Christian Ullrich <chris@chrullrich.net> writes:
> * Tom Lane wrote:
> +       <para>
> +        Add new SSPI authentication parameters <varname>compat_realm</>
> +        and <varname>upn_usename</>, to make it possible to make SSPI
> +        work more like GSSAPI (Christian Ullrich)
> +       </para>

> It is upn_username, not usename. Typo in the commit message.

> "Make SSPI work more like GSSAPI" reads like it changed authentication 
> behavior in some fundamental way, and as if SSPI did not work like 
> GSSAPI without it. The difference in behavior of include_realm between 
> GSSAPI and SSPI is not caused by SSPI, but is an implementation detail 
> on our end.

> I suggest writing "use the Kerberos realm name for authentication 
> instead of the NetBIOS name" either in place of the existing description 
> or together with it.

OK, how about this:
      <para>       Add new SSPI authentication parameters <varname>compat_realm</>       and <varname>upn_username</>,
tocontrol whether NetBIOS or Kerberos       realm names and user names are used during SSPI authentication
(ChristianUllrich)      </para>
 

BTW, I went to read the descriptions of those parameters again, and this
one seems a bit confusing:
    <varlistentry>     <term><literal>compat_realm</literal></term>     <listitem>      <para>       If set to 1, the
domain'sSAM-compatible name (also known as the       NetBIOS name) is used for the <literal>include_realm</literal>
 option. This is the default. If set to 0, the true realm name from       the Kerberos user principal name is used.
</para>      <para>       Do not enable this option unless your server runs under a domain       account (this includes
virtualservice accounts on a domain member       system) and all clients authenticating through SSPI are also using
 domain accounts, or authentication will fail.      </para>     </listitem>    </varlistentry>
 

To my mind, an option that's set to 1 is "enabled".  Should the second
para read "Do not disable ..."?  Or maybe we should reverse the sense
of the flag, so that the default state can be 0 == disabled?
        regards, tom lane

<listitem>
<!--
2015-11-06 [a76ef15d9] Add sort support routine for the UUID data type.
2016-02-03 [b47b4dbf6] Extend sortsupport for text to more opclasses.
2016-02-17 [f1f5ec1ef] Reuse abbreviated keys in ordered [set] aggregates.
-->      <para>       Speed up sorting of <type>uuid</>, <type>bytea</>,       and <type>char(n)</> fields by using
<quote>abbreviated</>keys       (Peter Geoghegan)      </para>
 
      <para>       Support for abbreviated keys has also been added to the non-default       operator classes
<literal>text_pattern_ops</>,      <literal>varchar_pattern_ops</>, and <literal>bpchar_pattern_ops</>.
Processingof ordered-set aggregates can also now exploit       abbreviated keys.      </para>     </listitem>
 

Is it really sensible to group f1f5ec1ef together with the others?  I
think that one should be its own entry.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Is it really sensible to group f1f5ec1ef together with the others?  I
> think that one should be its own entry.

Peter seemed happy with the idea, cf
http://www.postgresql.org/message-id/CAM3SWZSOOUY3eqUZiC32he-FxycCxfV5rKots-8OF20rZgcx7g@mail.gmail.com
        regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Is it really sensible to group f1f5ec1ef together with the others?  I
> > think that one should be its own entry.
> 
> Peter seemed happy with the idea, cf
> http://www.postgresql.org/message-id/CAM3SWZSOOUY3eqUZiC32he-FxycCxfV5rKots-8OF20rZgcx7g@mail.gmail.com

Oh, okay.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Tom Lane wrote:

> Christian Ullrich <chris@chrullrich.net> writes:

>> I suggest writing "use the Kerberos realm name for authentication
>> instead of the NetBIOS name" either in place of the existing description
>> or together with it.
>
> OK, how about this:
>
>        <para>
>         Add new SSPI authentication parameters <varname>compat_realm</>
>         and <varname>upn_username</>, to control whether NetBIOS or Kerberos
>         realm names and user names are used during SSPI authentication
>         (Christian Ullrich)
>        </para>

Perfect, except for the implied idea of a "NetBIOS realm name", see 
below. I can live with that in release notes, though.

> BTW, I went to read the descriptions of those parameters again, and this
> one seems a bit confusing:
>
>      <varlistentry>
>       <term><literal>compat_realm</literal></term>
>       <listitem>
>        <para>
>         If set to 1, the domain's SAM-compatible name (also known as the
>         NetBIOS name) is used for the <literal>include_realm</literal>
>         option. This is the default. If set to 0, the true realm name from
>         the Kerberos user principal name is used.
>        </para>
>        <para>
>         Do not enable this option unless your server runs under a domain
>         account (this includes virtual service accounts on a domain member
>         system) and all clients authenticating through SSPI are also using
>         domain accounts, or authentication will fail.
>        </para>
>       </listitem>
>      </varlistentry>
>
> To my mind, an option that's set to 1 is "enabled".  Should the second
> para read "Do not disable ..."?  Or maybe we should reverse the sense
> of the flag, so that the default state can be 0 == disabled?

Well spotted, thanks. It should be "disable" instead.

This is left from when the sense of the option _was_ the other way 
around (it was called "real_realm" then). I reversed and renamed it 
after Magnus reviewed the patch and was -- correctly -- opposed to the name.

If the default state should be off, we're back to inventing a useful new 
name. Magnus suggested "sspi_netbios_realm", which could be shortened to 
just "netbios_realm", but I don't like to have both "NetBIOS" and 
"realm" in the name because nobody else calls a domain's NetBIOS name a 
"realm". (For the release notes, on the other hand, there is no need to 
split this hair quite so thin.)

Unless you _really_ want the default (that is, backwards compatible) 
behavior with the option off, I would rather keep it the way it is.

-- 
Christian

Christian Ullrich <chris@chrullrich.net> writes:
> * Tom Lane wrote:
>> To my mind, an option that's set to 1 is "enabled".  Should the second
>> para read "Do not disable ..."?  Or maybe we should reverse the sense
>> of the flag, so that the default state can be 0 == disabled?

> Well spotted, thanks. It should be "disable" instead.

> This is left from when the sense of the option _was_ the other way 
> around (it was called "real_realm" then). I reversed and renamed it 
> after Magnus reviewed the patch and was -- correctly -- opposed to the name.

Oh, OK, I don't wish to re-open the issue if it's already been thought
about.  Will just s/enable/disable/ instead.
        regards, tom lane