Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Christian Ullrich  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Christian Ullrich]

* Tom Lane wrote:


Christian Ullrich  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:

   
Add new SSPI authentication parameters compat_realm
and upn_username, to control whether NetBIOS or Kerberos
realm names and user names are used during SSPI authentication
(Christian Ullrich)
   


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:

 
  compat_realm
  
   
If set to 1, the domain's SAM-compatible name (also known as the
NetBIOS name) is used for the include_realm
option. This is the default. If set to 0, the true realm name from
the Kerberos user principal name is used.
   
   
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.
   
  
 

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



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Alvaro Herrera]

Tom Lane wrote:
> Alvaro Herrera  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-8of20rzgc...@mail.gmail.com

Oh, okay.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Alvaro Herrera  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-8of20rzgc...@mail.gmail.com

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

Re: [HACKERS] Initial release notes created for 9.6

[Alvaro Herrera]

  

   
Speed up sorting of uuid, bytea,
and char(n) fields by using abbreviated keys
(Peter Geoghegan)
   

   
Support for abbreviated keys has also been added to the non-default
operator classes text_pattern_ops,
varchar_pattern_ops, and bpchar_pattern_ops.
Processing of ordered-set aggregates can also now exploit
abbreviated keys.
   
  

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

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Christian Ullrich  writes:
> * Tom Lane wrote:
> +   
> +Add new SSPI authentication parameters compat_realm
> +and upn_usename, to make it possible to make SSPI
> +work more like GSSAPI (Christian Ullrich)
> +   

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

   
Add new SSPI authentication parameters compat_realm
and upn_username, to control whether NetBIOS or Kerberos
realm names and user names are used during SSPI authentication
(Christian Ullrich)
   

BTW, I went to read the descriptions of those parameters again, and this
one seems a bit confusing:

 
  compat_realm
  
   
If set to 1, the domain's SAM-compatible name (also known as the
NetBIOS name) is used for the include_realm
option. This is the default. If set to 0, the true realm name from
the Kerberos user principal name is used.
   
   
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.
   
  
 

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Jeff Janes  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

   
Avoid some unnecessary cancellations of hot-standby queries during
replay of actions that take AccessExclusiveLocks (Jeff Janes)
   

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

Re: [HACKERS] Initial release notes created for 9.6

[Christian Ullrich]

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


+
+   
+Add new SSPI authentication parameters compat_realm
+and upn_usename, to make it possible to make SSPI
+work more like GSSAPI (Christian Ullrich)
+   

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





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Jeff Janes]

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

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Amit Kapila]

On Fri, May 6, 2016 at 12:11 AM, Robert Haas  wrote:
>
> On Thu, May 5, 2016 at 1:32 PM, Tom Lane  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 think with PostgreSQL 9.6, the OLTP workloads (short queries) will see a
major performance improvement for both read-write as well as read-only
workloads mainly due to below features (there could be others as well, but
this is what comes to my mind first):

Replace shared-buffer header spinlocks with atomic operations to improve
scalability
Partition the freelist for shared hash tables, to reduce contention on
many-CPU servers
Reduce contention for the ProcArrayLock
Where feasible, trigger kernel writeback after a configurable number of
writes
Increase the number of clog buffers for better scalability

I think we should add that as a significant change.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Initial release notes created for 9.6

[Alvaro Herrera]

Andres Freund wrote:

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

> +
> +   
> +Add pg_config
> +system view to expose the same information available from
> +the pg_config utility (Joe Conway)
> +   
> +  
> 
> 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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Peter Geoghegan]

On Thu, May 5, 2016 at 7:42 PM, Tom Lane  wrote:
> Peter Geoghegan  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Peter Geoghegan  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Andres Freund  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

Re: [HACKERS] Initial release notes created for 9.6

[Andres Freund]

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:

+
+   
+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)
+   
+
+   
+The new configuration parameters
+,
+,
+, and
+ control this behavior.
+   
+  

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

+
+   
+Extend relations multiple blocks at a time (Dilip Kumar)
+   
+
+   
+This reduces kernel traffic, and improves scalability when multiple
+processes are inserting into the same relation.
+   
+  

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?

+
+   
+Improve performance by moving buffer content locks into the buffer
+descriptors (Andres Freund, Simon Riggs)
+   
+  

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.


+
+   
+Add pg_config
+system view to expose the same information available from
+the pg_config utility (Joe Conway)
+   
+  

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


+  
+
+   
+Ensure that invalidation messages are recorded in WAL even when
+issued by a transaction that has no XID assigned (Andres Freund)
+   
+
+   
+This fixes some corner cases in which transactions on standby
+servers failed to notice changes such as new indexes.
+   
+  

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.

+  
+
+   
+If a CHECK constraint is declared NOT VALID in
+a table creation command, automatically mark it valid (Amit Langote,
+Amul Sul)
+   
+
+   
+This matches the longstanding behavior of FOREIGN KEY
+constraints.
+   
+  

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


+
+  
+
+   
+Treat role names beginning with pg_ as reserved
+(Stephen Frost)
+   
+
+   
+User creation of such role names is now disallowed.  This prevents
+conflicts with built-in roles created by initdb.
+   
+  

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


+  
+
+   
+Fix text search parser to allow leading digits in email
+and host tokens (Artur Zakirov)
+   
+
+   
+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 tsvector columns and indexes, so
+that addresses of this form will be found properly by text searches.
+   
+  

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

Re: [HACKERS] Initial release notes created for 9.6

[Peter Geoghegan]

On Thu, May 5, 2016 at 10:32 AM, Tom Lane  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.gh...@momjian.us
-- 
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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Masahiko Sawada  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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Peter Geoghegan  writes:
> On Thu, May 5, 2016 at 5:54 PM, Tom Lane  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

Re: [HACKERS] Initial release notes created for 9.6

[Masahiko Sawada]

On Fri, May 6, 2016 at 2: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.
>

+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

Re: [HACKERS] Initial release notes created for 9.6

[Peter Geoghegan]

On Thu, May 5, 2016 at 5:54 PM, Tom Lane  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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

I wrote:
> Michael Paquier  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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Vitaly Burovoy  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

Re: [HACKERS] Initial release notes created for 9.6

[Vitaly Burovoy]

On 5/5/16, Tom Lane  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-20df0e4b5...@postgrespro.ru
[3] 
http://www.postgresql.org/message-id/caezatcxhz5ggfrfcf9_yw5h6wdxr68qdfiwhvmgfr3ascnq...@mail.gmail.com
-- 
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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Michael Paquier  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

Re: [HACKERS] Initial release notes created for 9.6

[Michael Paquier]

On Fri, May 6, 2016 at 7:53 AM, Tom Lane  wrote:
> Andres Freund  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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

Andres Freund  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

Re: [HACKERS] Initial release notes created for 9.6

[Andres Freund]

On 2016-05-05 16:25:38 -0400, Robert Haas wrote:
> On Thu, May 5, 2016 at 1:32 PM, Tom Lane  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

> +
> +   
> +Use atomic operations, rather than a spinlock, to protect an LWLock's
> +wait queue (Andres Freund)
> +   
> +  
> +
> +  
> 
> 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

Re: [HACKERS] Initial release notes created for 9.6

[Robert Haas]

On Thu, May 5, 2016 at 1:32 PM, Tom Lane  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.

+   
+Extend relations multiple blocks at a time (Dilip Kumar)
+   
+
+   
+This reduces kernel traffic, and improves scalability when multiple
+processes are inserting into the same relation.
+   
+  

I think this should be rephrased so as to make it clear that we only
do this when there is contention.

+
+   
+Use atomic operations, rather than a spinlock, to protect an LWLock's
+wait queue (Andres Freund)
+   
+  
+
+  

This was basically an attempt to cure a defect in 48354581a and could
perhaps be lumped under that item.

+   
+Force backends to exit if the postmaster dies
+(Rajeev Rastogi and Robert Haas)
+   
+

Separator between names should probably be a comma rather than "and".

+   
+Ensure that trigonometric functions handle infinity and NaN inputs per
+spec (Dean Rasheed)
+   

"per spec" is pretty vague. What spec?  And how about spelling out
"specification"?

+   
+An example usage is 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.
+   

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

+   
+This function converts strings like those produced
+by pg_size_pretty() into sizes in bytes.  An example
+usage is WHERE pg_total_relation_size(oid) 
+pg_size_bytes('10 GB').
+   

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

+   
+In pg_size_pretty(), format negative numbers similarly to
+positive ones (Adrian Vondendriesch)
+   

Maybe add: "Previously, the suffix for a negative number was always
'bytes', never 'kB', 'MB', 'GB', or 'TB'".  Or something like that.

+   
+Add an optional missing_ok argument to
+the current_setting() function (David Christensen)
+   

Adjust text to clarify that it suppresses the error for a nonexisting setting?

+   
+Improve error reporting during initdb's post-bootstrap
+phase, by not reporting the entire input file as the failing
+query (Tom Lane)
+   

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

+   
+Consider performing sorts on the remote server (Ashutosh Bapat)
+   
+  
+
+  
+
+   
+Push down joins to the remote server when possible (Shigeru Hanada,
+Ashutosh Bapat)
+   

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

Re: [HACKERS] Initial release notes created for 9.6

[Robert Haas]

On Thu, May 5, 2016 at 1:32 PM, Tom Lane  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.3020...@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

Re: [HACKERS] Initial release notes created for 9.6

[Robert Haas]

On Thu, May 5, 2016 at 1:32 PM, 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.

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, 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 ."

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

Re: [HACKERS] Initial release notes created for 9.6

[Tom Lane]

"Joshua D. Drake"  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Initial release notes created for 9.6

[Joshua D. Drake]

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

[HACKERS] Initial release notes created for 9.6

[Tom Lane]

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