pg.ddx.io pgsql-www@postgresql.org mailing list archive
help / color / mirror / Atom feedPostgres 11 release notes
181+ messages / 42 participants
[nested] [flat]
Commits from this thread:
2018-05-15 185f4f84d5 doc: clarify SCRAM channel binding
* Postgres 11 release notes
@ 2018-05-11 15:08 Bruce Momjian <bruce@momjian.us>
0 siblings, 23 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 15:08 UTC (permalink / raw)
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
I have committed the first draft of the Postgres 11 release notes. I
will add more markup soon. You can view the most current version here:
http://momjian.us/pgsql_docs/release-11.html
I expect a torrent of feedback. ;-)
On a personal note, I want to apologize for not adequately championing
two features that I think have strategic significance but didn't make it
into Postgres 11: parallel FDW access and improved multi-variate
statistics. I hope to do better job during Postgres 12.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 16:29 Fabien COELHO <coelho@cri.ensmp.fr>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Fabien COELHO @ 2018-05-11 16:29 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hello Bruce,
> http://momjian.us/pgsql_docs/release-11.html
> I expect a torrent of feedback. ;-)
Here is some, for things I know about:
>> Add major scripting features to pgbench (Fabien Coelho)
I assume that you are refering to "bc7fa0c1". I do not think that anything
qualifies as "major".
I would rather describe it as "Add support for NULL and boolean, as well
as assorted operators and functions, to pgbench expressions". Or something
in better English.
>> Add \if macro support to pgbench (Fabien Coelho)
I would remove the word "macro", as it is not a pre-compilation feature,
it is just a somehow simple standard conditional.
> On a personal note, I want to apologize for not adequately championing
> two features that I think have strategic significance but didn't make it
> into Postgres 11: parallel FDW access and improved multi-variate
> statistics.
I'm planning to try to help with the later.
--
Fabien.
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 16:49 Teodor Sigaev <teodor@sigaev.ru>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Teodor Sigaev @ 2018-05-11 16:49 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Bruce Momjian wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
Hi!
Seems, you miss:
857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup of
B-tree indexes when possible
c0cbe00fee6d0a5e0ec72c6d68a035e674edc4cc Add explicit cast from scalar jsonb to
all numeric and bool types.
Pls, edit:
Add functionjson(b)_to_tsvector to create usable text search queries matching
JSON/JSONB values (Dmitry Dolgov)
to
Add function json(b)_to_tsvector to create usable vectors to search in json(b)
(Dmitry Dolgov)
or somehow else. Your wording is about query but actually that functions are
about how to create tsvector from json(b)
Thank you!
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 17:40 Chapman Flack <chap@anastigmatix.net>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Chapman Flack @ 2018-05-11 17:40 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 05/11/2018 11:08 AM, Bruce Momjian wrote:
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
Very superficial things:
Add predicate locking for Hash, GiST, and GIN indexes
s/likelyhood/likelihood/
Add extension jsonb_plpython
There are two such entries; one looks like it should be plperl.
Improve the speed of aggregate computations
This entry is missing a bullet.
-Chap
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 18:01 Bruce Momjian <bruce@momjian.us>
parent: Fabien COELHO <coelho@cri.ensmp.fr>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 18:01 UTC (permalink / raw)
To: Fabien COELHO <coelho@cri.ensmp.fr>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 06:29:39PM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > http://momjian.us/pgsql_docs/release-11.html
>
> >I expect a torrent of feedback. ;-)
>
> Here is some, for things I know about:
>
> >>Add major scripting features to pgbench (Fabien Coelho)
>
> I assume that you are refering to "bc7fa0c1". I do not think that anything
> qualifies as "major".
>
> I would rather describe it as "Add support for NULL and boolean, as well as
> assorted operators and functions, to pgbench expressions". Or something in
> better English.
OK, new wording is:
Add pgbench expressions support for NULLs, booleans, and some
functions and operators (Fabien Coelho)
> >>Add \if macro support to pgbench (Fabien Coelho)
>
> I would remove the word "macro", as it is not a pre-compilation feature, it
> is just a somehow simple standard conditional.
New wording is:
Add \if conditional support to pgbench (Fabien Coelho)
> >On a personal note, I want to apologize for not adequately championing
> >two features that I think have strategic significance but didn't make it
> >into Postgres 11: parallel FDW access and improved multi-variate
> >statistics.
>
> I'm planning to try to help with the later.
Great, thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 18:44 Bruce Momjian <bruce@momjian.us>
parent: Teodor Sigaev <teodor@sigaev.ru>
0 siblings, 2 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 18:44 UTC (permalink / raw)
To: Teodor Sigaev <teodor@sigaev.ru>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 07:49:50PM +0300, Teodor Sigaev wrote:
>
>
> Bruce Momjian wrote:
> >I have committed the first draft of the Postgres 11 release notes. I
> >will add more markup soon. You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> >I expect a torrent of feedback. ;-)
> Hi!
>
> Seems, you miss:
> 857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
> of B-tree indexes when possible
I read that and thought it was too details to be in the release notes.
It is not that it is unimportant, but it is hard to see how people would
notice the difference or change their behavior based on this change.
> c0cbe00fee6d0a5e0ec72c6d68a035e674edc4cc Add explicit cast from scalar jsonb
> to all numeric and bool types.
>
> Pls, edit:
> Add functionjson(b)_to_tsvector to create usable text search queries
> matching JSON/JSONB values (Dmitry Dolgov)
> to
> Add function json(b)_to_tsvector to create usable vectors to search in
> json(b) (Dmitry Dolgov)
> or somehow else. Your wording is about query but actually that functions are
> about how to create tsvector from json(b)
OK, how is this text?
Add function <function>json(b)_to_tsvector()</function> to create
text search query for matching <type>JSON</type>/<type>JSONB
</type>values (Dmitry Dolgov)
I have made this change but can adjust it some more.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 18:50 Bruce Momjian <bruce@momjian.us>
parent: Chapman Flack <chap@anastigmatix.net>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 18:50 UTC (permalink / raw)
To: Chapman Flack <chap@anastigmatix.net>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 01:40:54PM -0400, Chapman Flack wrote:
> On 05/11/2018 11:08 AM, Bruce Momjian wrote:
>
> > http://momjian.us/pgsql_docs/release-11.html
> >
> > I expect a torrent of feedback. ;-)
>
> Very superficial things:
>
>
> Add predicate locking for Hash, GiST, and GIN indexes
>
> s/likelyhood/likelihood/
>
> Add extension jsonb_plpython
>
> There are two such entries; one looks like it should be plperl.
>
> Improve the speed of aggregate computations
>
> This entry is missing a bullet.
Great, all fixed, and the URL contents are updated with this and
previous suggestions, plus more markup.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 18:50 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-05-11 18:50 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018-05-11 14:44:06 -0400, Bruce Momjian wrote:
> On Fri, May 11, 2018 at 07:49:50PM +0300, Teodor Sigaev wrote:
> >
> >
> > Bruce Momjian wrote:
> > >I have committed the first draft of the Postgres 11 release notes. I
> > >will add more markup soon. You can view the most current version here:
> > >
> > > http://momjian.us/pgsql_docs/release-11.html
> > >
> > >I expect a torrent of feedback. ;-)
> > Hi!
> >
> > Seems, you miss:
> > 857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
> > of B-tree indexes when possible
>
> I read that and thought it was too details to be in the release notes.
> It is not that it is unimportant, but it is hard to see how people would
> notice the difference or change their behavior based on this change.
It's a *huge* performance problem in larger installations
currently. When you have a multi-TB relation and correspondingly large
relation, the VM allows to make the heap cleanups cheap, but then the
index scan takes just about forever. I know at least one large PG user
that moved off postgres because of it. This won't solve all of those
concerns, but it definitely is crucial to know for such users.
People would notice by vacuums of large relations not taking forever
anymore. And the behaviour change would be to a) upgrade b) tune the
associated reloption/GUC.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 18:59 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 18:59 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 11:50:51AM -0700, Andres Freund wrote:
> On 2018-05-11 14:44:06 -0400, Bruce Momjian wrote:
> > On Fri, May 11, 2018 at 07:49:50PM +0300, Teodor Sigaev wrote:
> > >
> > >
> > > Bruce Momjian wrote:
> > > >I have committed the first draft of the Postgres 11 release notes. I
> > > >will add more markup soon. You can view the most current version here:
> > > >
> > > > http://momjian.us/pgsql_docs/release-11.html
> > > >
> > > >I expect a torrent of feedback. ;-)
> > > Hi!
> > >
> > > Seems, you miss:
> > > 857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
> > > of B-tree indexes when possible
> >
> > I read that and thought it was too details to be in the release notes.
> > It is not that it is unimportant, but it is hard to see how people would
> > notice the difference or change their behavior based on this change.
>
> It's a *huge* performance problem in larger installations
> currently. When you have a multi-TB relation and correspondingly large
> relation, the VM allows to make the heap cleanups cheap, but then the
> index scan takes just about forever. I know at least one large PG user
> that moved off postgres because of it. This won't solve all of those
> concerns, but it definitely is crucial to know for such users.
>
> People would notice by vacuums of large relations not taking forever
> anymore. And the behaviour change would be to a) upgrade b) tune the
> associated reloption/GUC.
OK, so what is the text that people will understand? This?
Prevent manual VACUUMs on append-only tables from performing
needless index scans
You can see why I was hesitant to include it, based on this text, but I
am happy to add it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 18:59 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 2 replies; 181+ messages in thread
From: Andres Freund @ 2018-05-11 18:59 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
Quick notes:
> <para>
> Add Just-In-Time (<acronym>JIT</acronym>) compilation of plans
> run the by the executor
>(Andres Freund)
> </para>
> </listitem>
It's currently not yet compilation of entire plans, but only parts. I
think that's a relevant distinction because I'd like to add that as a
feature to v12 ;). How about just adding 'parts of' or such? I'd also
rephrase the plan and 'run by the executor a bit'. How about:
Add Just-In-Time (<acronym>JIT</acronym>) compilation of parts of
queries, to accelerate their execution.
> <listitem>
><!--
>2018-03-20 [5b2526c83] Add configure infrastructure (- -with-llvm) to enable LLV
>-->
>
> <para>
> Add configure flag <option>--with-llvm</option> to test for
> <acronym>LLVM</acronym> support (Andres Freund)
> </para>
> </listitem>
>
> <listitem>
><!--
>2018-03-20 [6869b4f25] Add C++ support to configure.
>-->
>
> <para>
> Have configure check for the availability of a C++ compiler
> (Andres Freund)
> </para>
> </listitem>
>
> <listitem>
I wonder if we shouldn't omit those, considering them part of the JIT
entry? Not quite sure what our policy there is.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:00 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Alvaro Herrera @ 2018-05-11 19:00 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Bruce Momjian wrote:
> OK, so what is the text that people will understand? This?
>
> Prevent manual VACUUMs on append-only tables from performing
> needless index scans
Make vacuum cheaper by avoiding scans of btree indexes when not
necessary
?
Why "manual vacuum"? It's a problem with vacuums invoked from
autovacuum too.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:02 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 181+ messages in thread
From: Alvaro Herrera @ 2018-05-11 19:02 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Andres Freund wrote:
> > <para>
> > Add configure flag <option>--with-llvm</option> to test for
> > <acronym>LLVM</acronym> support (Andres Freund)
> > </para>
> > <para>
> > Have configure check for the availability of a C++ compiler
> > (Andres Freund)
> > </para>
>
> I wonder if we shouldn't omit those, considering them part of the JIT
> entry? Not quite sure what our policy there is.
I don't see why users would be interested in these items at all, so +1
for omitting them.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:04 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-05-11 19:04 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018-05-11 14:59:04 -0400, Bruce Momjian wrote:
> On Fri, May 11, 2018 at 11:50:51AM -0700, Andres Freund wrote:
> > On 2018-05-11 14:44:06 -0400, Bruce Momjian wrote:
> > > On Fri, May 11, 2018 at 07:49:50PM +0300, Teodor Sigaev wrote:
> > > >
> > > >
> > > > Bruce Momjian wrote:
> > > > >I have committed the first draft of the Postgres 11 release notes. I
> > > > >will add more markup soon. You can view the most current version here:
> > > > >
> > > > > http://momjian.us/pgsql_docs/release-11.html
> > > > >
> > > > >I expect a torrent of feedback. ;-)
> > > > Hi!
> > > >
> > > > Seems, you miss:
> > > > 857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
> > > > of B-tree indexes when possible
> > >
> > > I read that and thought it was too details to be in the release notes.
> > > It is not that it is unimportant, but it is hard to see how people would
> > > notice the difference or change their behavior based on this change.
> >
> > It's a *huge* performance problem in larger installations
> > currently. When you have a multi-TB relation and correspondingly large
> > relation, the VM allows to make the heap cleanups cheap, but then the
> > index scan takes just about forever. I know at least one large PG user
> > that moved off postgres because of it. This won't solve all of those
> > concerns, but it definitely is crucial to know for such users.
> >
> > People would notice by vacuums of large relations not taking forever
> > anymore. And the behaviour change would be to a) upgrade b) tune the
> > associated reloption/GUC.
>
> OK, so what is the text that people will understand? This?
>
> Prevent manual VACUUMs on append-only tables from performing
> needless index scans
I don't think the table being 'append-only' is necessary? Nor does it
have to be a manual vacuum. And 'needless index scan' sounds less than
it is/was, namely a full scan of the index. Perhaps something like:
Allow vacuum to skip doing a full scan of btree indexes after VACUUM,
if not necessary.
or something like that?
> You can see why I was hesitant to include it, based on this text, but I
> am happy to add it.
I can't. Even if the above were accurate it'd be relevant information.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:11 Bruce Momjian <bruce@momjian.us>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 19:11 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Andres Freund <andres@anarazel.de>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 04:00:58PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > OK, so what is the text that people will understand? This?
> >
> > Prevent manual VACUUMs on append-only tables from performing
> > needless index scans
>
> Make vacuum cheaper by avoiding scans of btree indexes when not
> necessary
> ?
>
> Why "manual vacuum"? It's a problem with vacuums invoked from
> autovacuum too.
Uh, from the commit it says:
When workload on particular table is append-only, then autovacuum
isn't intended to touch this table. However, user may run vacuum
manually in order to fill visibility map and get benefits of
--------
index-only scans. Then ambulkdelete wouldn't be called for
indexes of such table (because no heap tuples were deleted), only
---------------------------
amvacuumcleanup would be called In this case, amvacuumcleanup
would perform full index scan for two objectives: put recyclable
pages into free space map and update index statistics.
Why would autovacuum run on a table with no expired index entries?
Personally, I think the fact that autovacuum doesn't run on suvch tables
and therefore doesn't automatically do index-only scans is a problem. I
tried to fix it years ago, but failed and gave up.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:14 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 19:14 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 11:59:12AM -0700, Andres Freund wrote:
> Hi,
>
> Quick notes:
> > <para>
> > Add Just-In-Time (<acronym>JIT</acronym>) compilation of plans
> > run the by the executor
> >(Andres Freund)
> > </para>
> > </listitem>
>
> It's currently not yet compilation of entire plans, but only parts. I
> think that's a relevant distinction because I'd like to add that as a
> feature to v12 ;). How about just adding 'parts of' or such? I'd also
> rephrase the plan and 'run by the executor a bit'. How about:
>
> Add Just-In-Time (<acronym>JIT</acronym>) compilation of parts of
> queries, to accelerate their execution.
OK, new text:
Add Just-In-Time (<acronym>JIT</acronym>) compilation of some
parts of query plans to improve execution speed (Andres Freund)
> > <listitem>
> ><!--
> >2018-03-20 [5b2526c83] Add configure infrastructure (- -with-llvm) to enable LLV
> >-->
> >
> > <para>
> > Add configure flag <option>--with-llvm</option> to test for
> > <acronym>LLVM</acronym> support (Andres Freund)
> > </para>
> > </listitem>
> >
> > <listitem>
> ><!--
> >2018-03-20 [6869b4f25] Add C++ support to configure.
> >-->
> >
> > <para>
> > Have configure check for the availability of a C++ compiler
> > (Andres Freund)
> > </para>
> > </listitem>
> >
> > <listitem>
>
> I wonder if we shouldn't omit those, considering them part of the JIT
> entry? Not quite sure what our policy there is.
OK, removed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:17 Peter Geoghegan <pg@bowt.ie>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 181+ messages in thread
From: Peter Geoghegan @ 2018-05-11 19:17 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 12:04 PM, Andres Freund <andres@anarazel.de> wrote:
> I don't think the table being 'append-only' is necessary? Nor does it
> have to be a manual vacuum. And 'needless index scan' sounds less than
> it is/was, namely a full scan of the index. Perhaps something like:
>
> Allow vacuum to skip doing a full scan of btree indexes after VACUUM,
> if not necessary.
>
> or something like that?
I suggest "Allow vacuuming to avoid full index scans for indexes when
there are no dead tuples found in a table. Where necessary, the
behavior can be adjusted via the new configuration parameter
vacuum_cleanup_index_scale_factor."
Also:
* "Allow indexes to be built in parallel" should specify that it only
works for B-Tree index builds.
* Suggest replacement sort item be phrased as: "Remove the
configuration parameter replacement_sort_tuples. <newline> The
replacement selection sort algorithm is no longer used."
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:20 Teodor Sigaev <teodor@sigaev.ru>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Teodor Sigaev @ 2018-05-11 19:20 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
>> 857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
>> of B-tree indexes when possible
>
> I read that and thought it was too details to be in the release notes.
> It is not that it is unimportant, but it is hard to see how people would
> notice the difference or change their behavior based on this change.
Hm, it could be something like:
Add possibility to miss scan indexes on append-only table, it decreases
vacuum time on such tables.
>
>> c0cbe00fee6d0a5e0ec72c6d68a035e674edc4cc Add explicit cast from scalar jsonb
>> to all numeric and bool types.
>>
>> Pls, edit:
>> Add functionjson(b)_to_tsvector to create usable text search queries
>> matching JSON/JSONB values (Dmitry Dolgov)
>> to
>> Add function json(b)_to_tsvector to create usable vectors to search in
>> json(b) (Dmitry Dolgov)
>> or somehow else. Your wording is about query but actually that functions are
>> about how to create tsvector from json(b)
>
> OK, how is this text?
>
> Add function <function>json(b)_to_tsvector()</function> to create
> text search query for matching <type>JSON</type>/<type>JSONB
> </type>values (Dmitry Dolgov)
Not query - *_to_tsvector functions produce a tsvector. So:
Add function <function>json(b)_to_tsvector()</function> to use
customizable full text search over json(b) columns.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:22 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-05-11 19:22 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018-05-11 15:11:31 -0400, Bruce Momjian wrote:
> On Fri, May 11, 2018 at 04:00:58PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > OK, so what is the text that people will understand? This?
> > >
> > > Prevent manual VACUUMs on append-only tables from performing
> > > needless index scans
> >
> > Make vacuum cheaper by avoiding scans of btree indexes when not
> > necessary
> > ?
> >
> > Why "manual vacuum"? It's a problem with vacuums invoked from
> > autovacuum too.
>
> Uh, from the commit it says:
>
> When workload on particular table is append-only, then autovacuum
> isn't intended to touch this table. However, user may run vacuum
> manually in order to fill visibility map and get benefits of
> --------
> index-only scans. Then ambulkdelete wouldn't be called for
> indexes of such table (because no heap tuples were deleted), only
> ---------------------------
> amvacuumcleanup would be called In this case, amvacuumcleanup
> would perform full index scan for two objectives: put recyclable
> pages into free space map and update index statistics.
>
> Why would autovacuum run on a table with no expired index entries?
Anti-Wraparound is one case. One where it's really painful to take
forever on lots of unchanged tables. Lots of hot updates another.
Btw, is it just me, or do the commit and docs confuse say stalled when
stale is intended?
> Personally, I think the fact that autovacuum doesn't run on suvch tables
> and therefore doesn't automatically do index-only scans is a problem. I
> tried to fix it years ago, but failed and gave up.
I'm really unhappy about that too.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:26 Justin Pryzby <pryzby@telsasoft.com>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 181+ messages in thread
From: Justin Pryzby @ 2018-05-11 19:26 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; Alvaro Herrera <alvherre@2ndquadrant.com>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 12:22:08PM -0700, Andres Freund wrote:
> Btw, is it just me, or do the commit and docs confuse say stalled when
> stale is intended?
Should be fixed since yesterday's 8e12f4a250d250a89153da2eb9b91c31bb80c483 ?
Justin
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 19:28 Peter Geoghegan <pg@bowt.ie>
parent: Peter Geoghegan <pg@bowt.ie>
1 sibling, 1 reply; 181+ messages in thread
From: Peter Geoghegan @ 2018-05-11 19:28 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 12:17 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> * Suggest replacement sort item be phrased as: "Remove the
> configuration parameter replacement_sort_tuples. <newline> The
> replacement selection sort algorithm is no longer used."
Also, it should be moved to "Migration to Version 11", since the only
issue here is compatibility with older versions.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 21:03 Bruce Momjian <bruce@momjian.us>
parent: Peter Geoghegan <pg@bowt.ie>
1 sibling, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 21:03 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Andres Freund <andres@anarazel.de>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 12:17:47PM -0700, Peter Geoghegan wrote:
> On Fri, May 11, 2018 at 12:04 PM, Andres Freund <andres@anarazel.de> wrote:
> > I don't think the table being 'append-only' is necessary? Nor does it
> > have to be a manual vacuum. And 'needless index scan' sounds less than
> > it is/was, namely a full scan of the index. Perhaps something like:
> >
> > Allow vacuum to skip doing a full scan of btree indexes after VACUUM,
> > if not necessary.
> >
> > or something like that?
>
> I suggest "Allow vacuuming to avoid full index scans for indexes when
> there are no dead tuples found in a table. Where necessary, the
> behavior can be adjusted via the new configuration parameter
> vacuum_cleanup_index_scale_factor."
>
> Also:
>
> * "Allow indexes to be built in parallel" should specify that it only
> works for B-Tree index builds.
>
> * Suggest replacement sort item be phrased as: "Remove the
> configuration parameter replacement_sort_tuples. <newline> The
> replacement selection sort algorithm is no longer used."
All done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 21:04 Bruce Momjian <bruce@momjian.us>
parent: Peter Geoghegan <pg@bowt.ie>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 21:04 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Andres Freund <andres@anarazel.de>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 12:28:57PM -0700, Peter Geoghegan wrote:
> On Fri, May 11, 2018 at 12:17 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> > * Suggest replacement sort item be phrased as: "Remove the
> > configuration parameter replacement_sort_tuples. <newline> The
> > replacement selection sort algorithm is no longer used."
>
> Also, it should be moved to "Migration to Version 11", since the only
> issue here is compatibility with older versions.
Done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-11 21:06 Bruce Momjian <bruce@momjian.us>
parent: Teodor Sigaev <teodor@sigaev.ru>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-11 21:06 UTC (permalink / raw)
To: Teodor Sigaev <teodor@sigaev.ru>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 10:20:17PM +0300, Teodor Sigaev wrote:
> >>857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
> >>of B-tree indexes when possible
> >
> >I read that and thought it was too details to be in the release notes.
> >It is not that it is unimportant, but it is hard to see how people would
> >notice the difference or change their behavior based on this change.
> Hm, it could be something like:
> Add possibility to miss scan indexes on append-only table, it decreases
> vacuum time on such tables.
>
> >
> >>c0cbe00fee6d0a5e0ec72c6d68a035e674edc4cc Add explicit cast from scalar jsonb
> >>to all numeric and bool types.
> >>
> >>Pls, edit:
> >>Add functionjson(b)_to_tsvector to create usable text search queries
> >>matching JSON/JSONB values (Dmitry Dolgov)
> >>to
> >>Add function json(b)_to_tsvector to create usable vectors to search in
> >>json(b) (Dmitry Dolgov)
> >>or somehow else. Your wording is about query but actually that functions are
> >>about how to create tsvector from json(b)
> >
> >OK, how is this text?
> >
> > Add function <function>json(b)_to_tsvector()</function> to create
> > text search query for matching <type>JSON</type>/<type>JSONB
> > </type>values (Dmitry Dolgov)
> Not query - *_to_tsvector functions produce a tsvector. So:
>
> Add function <function>json(b)_to_tsvector()</function> to use customizable
> full text search over json(b) columns.
Done and URL updated.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-12 20:22 Peter Geoghegan <pg@bowt.ie>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Peter Geoghegan @ 2018-05-12 20:22 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 2:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Done and URL updated.
I have some feedback on "Allow NOT NULL to be added to columns without
requiring a table rewrite". I suggest that this be phrased as "Avoid a
table rewrite when ALTER TABLE ADD COLUMN sets a default value for a
column". Referencing the fact that Postgres was previously able to do
this with a NULL default doesn't seem to add anything.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-13 00:47 Bruce Momjian <bruce@momjian.us>
parent: Peter Geoghegan <pg@bowt.ie>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-13 00:47 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; +Cc: Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, May 12, 2018 at 01:22:55PM -0700, Peter Geoghegan wrote:
> On Fri, May 11, 2018 at 2:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > Done and URL updated.
>
> I have some feedback on "Allow NOT NULL to be added to columns without
> requiring a table rewrite". I suggest that this be phrased as "Avoid a
> table rewrite when ALTER TABLE ADD COLUMN sets a default value for a
> column". Referencing the fact that Postgres was previously able to do
> this with a NULL default doesn't seem to add anything.
Agreed, done:
Allow <command>ALTER TABLE</command> to add a non-null default
column without a table rewrite (Andrew Dunstan, Serge Rielau)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-13 06:43 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 2 replies; 181+ messages in thread
From: Michael Paquier @ 2018-05-13 06:43 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version
> here:
Thanks for gathering all the commits in one piece, Bruce.
> I expect a torrent of feedback. ;-)
I looked at the entries where my name shows up. Here is some feedback
with HEAD at 8c6227a2 (latest as of writing this message).
<para>
Add information_schema columns related to table constraints and
triggers (Michael Paquier)
</para>
The author of this entry is Peter Eisentraut, not me.
<para>
Channel binding requires the server end
of the <acronym>TLS</acronym> connection to
prove that it knows the password. The options are <link
linkend="libpq-scram-channel-binding"><option>scram_channel_binding=tls-unique</option></link>
and <option>scram_channel_binding=tls-server-end-point</option>.
</para>
This is not actually correct. Channel binding is an MITM prevention
mechanism which makes sure that after the SSL handshake the backend and
the frontend are still connected to the same things. "tls-unique" makes
sure that a connection is uniquely used using a hash of the TLS finish
message, and end-point makes sure that the endpoints are the same using
a hash of the server certificate.
<para>
WHAT DOES THIS DOC TEXT MEAN? "An empty value specifies that
the client will not use channel binding. The default value
is tls-unique."
</para>
This means that the client can choose to not use channel binding (which
sends a 'n' flag if you refer to the communication protocol of SCRAM),
even if the server has advertised to the client channel binding. So
this provides a way to disable the feature at will, an on/off switch if
you want. If a v10 libpq tries to connect to a v11 server, then it
won't use channel binding automatically. That may be worth adding to
the documentation as well.
<para>
Allow access to file system functions to be controlled by
<command>GRANT</command>/<command>REVOKE</command> permissions,
rather than super-user checks (Michael Paquier)
</para>
Author is Stephen Frost here.
<para>
Use <command>GRANT</command>/<command>REVOKE</command>
to control access to <link
linkend="lo-import"><function>lo_import()</function></link>
and <function>lo_export()</function> (Michael Paquier)
</para>
Tom Lane is a co-author here I think.
<para>
Add libpq parameter to allow physical and logical replication
connections (Michael Paquier)
</para>
This commit has just added documentation which was missing and
incomplete. I would suggest to remove it from the release notes as no
new feature has been added.
<para>
Add <link
linkend="app-pgreceivewal"><application>pg_receivewal</application></link>
option <option>--no-sync</option> to prevent synchronous
<acronym>WAL</acronym> writes (Michael Paquier)
</para>
Perhaps this should be rewritten? --no-sync just disables any fsync
calls for WAL segments, which is useful for tests, not recommended for
production environments.
<para>
Prevent <application>pg_rewind</application> from running as
<literal>root</literal> (Magnus Hagander)
</para>
This one's authorship is actually mine, after a bug I found :)
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-13 08:43 Đặng Minh Hướng <kakalot49@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Đặng Minh Hướng @ 2018-05-13 08:43 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hello Bruce,
Thanks for the greate work!
2018-05-12 0:08 GMT+09:00 Bruce Momjian <bruce@momjian.us>:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
I think the behavior change (from PostgreSQL 11) of power() with NaN below
also need to report to users as the major change.
related commit: 61b200e2f582d0886d9de947e182483339d881fd
6bdf1303b34bc630e8945ae3407ec7e8395c8fe5
Discussion:
https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
Thanks and best regards,
---
Dang Minh Huong
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-13 09:53 Amit Langote <amitlangote09@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Amit Langote @ 2018-05-13 09:53 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, May 12, 2018 at 12:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
Thank you for compiling this, Bruce!
> I expect a torrent of feedback. ;-)
The following item
+<!--
+2017-11-23 [05b6ec39d] Show partition info from psql \d+
+-->
+
+ <para>
+ Have psql \d+ show a partition count of zero (Amit Langote)
+ </para>
missed mentioning Ashutosh Bapat as an author.
Maybe, the item name and description text could be improved as follows:
+ <para>
+ Have psql \d+ always show the partition information (Amit
Langote, Ashutosh Bapat)
+ </para>
+
+ <para>
+ Previously partition information would not be displayed for a
partitioned table if
+ it had no partitions. Also indicate which partitions are
themselves partitioned.
+ </para>
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-13 11:10 Amit Kapila <amit.kapila16@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 2 replies; 181+ messages in thread
From: Amit Kapila @ 2018-05-13 11:10 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
>
Thanks for compiling the first draft. I think there are few things
which we should add to the Parallel Queries section. (a) commit
e89a71fb449af2ef74f47be1175f99956cf21524 -
Pass InitPlan values to workers via Gather (Merge). We can write
something like "Allow the part of the plan that references an initplan
to run in parallel" or "Parallelise queries containing initplans",
(b) "Parallelise queries that contains expensive functions in target
lists" (Commits - 3f90ec8597c3515e0d3190613b31491686027e4b and
11cf92f6e2e13c0a6e3f98be3e629e6bd90b74d5).
Both of these features can parallelize queries in many workloads. The
feature (a) has sped up some of the TPC-H queries especially the cases
where InitPlan itself contains Gather node and feature (b) is also
quite helpful with PostGIS functions, see
https://carto.com/blog/inside/postgres-parallel/
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-13 11:25 Amit Kapila <amit.kapila16@gmail.com>
parent: Amit Kapila <amit.kapila16@gmail.com>
1 sibling, 1 reply; 181+ messages in thread
From: Amit Kapila @ 2018-05-13 11:25 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 4:40 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I have committed the first draft of the Postgres 11 release notes. I
>> will add more markup soon. You can view the most current version here:
>>
>> http://momjian.us/pgsql_docs/release-11.html
>>
>> I expect a torrent of feedback. ;-)
>>
>
> Thanks for compiling the first draft.
>
One more comment on below item:
Allow entire hash index pages to be scanned (Ashutosh Sharma)
Previously each hash index entry has to be locked and scanned separately.
I think it is better to write the second line as "Previously for each
hash index entry, we need to refind the scan position within the page
and cuts down on lock/unlock traffic.".
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 00:26 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 2 replies; 181+ messages in thread
From: Michael Paquier @ 2018-05-14 00:26 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 03:43:08PM +0900, Michael Paquier wrote:
> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version
> > here:
>
> Thanks for gathering all the commits in one piece, Bruce.
>
> > I expect a torrent of feedback. ;-)
>
> I looked at the entries where my name shows up. Here is some feedback
> with HEAD at 8c6227a2 (latest as of writing this message).
A couple of extra notes while reading the HTML notes:
<para>
Add timeline information to the <link
linkend="backup-lowlevel-base-backup"><filename>backup_label</filename></link>
file (Simon Riggs)
</para>
This feature has been implemented by me, not Simon.
<para>
Document that <filename>pg_internal.init</filename> files do not
need to be included in the base backup (David Steele)
</para>
Does not seem necessary to add that in the release notes..
<para>
Cause large object permission checks
to happen on large object open, <link
linkend="lo-open"><function>lo_open()</function></link>, not
read/write (Tom Lane)
</para>
Co-authoring with Tom on this one.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 11:10 David Steele <david@pgmasters.net>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 181+ messages in thread
From: David Steele @ 2018-05-14 11:10 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On 5/13/18 8:26 PM, Michael Paquier wrote:
> On Sun, May 13, 2018 at 03:43:08PM +0900, Michael Paquier wrote:
>> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
>>> I have committed the first draft of the Postgres 11 release notes. I
>>> will add more markup soon. You can view the most current version
>>> here:
>>
>> Thanks for gathering all the commits in one piece, Bruce.
>>
>>> I expect a torrent of feedback. ;-)
>>
>> I looked at the entries where my name shows up. Here is some feedback
>> with HEAD at 8c6227a2 (latest as of writing this message).
>
> <para>
> Document that <filename>pg_internal.init</filename> files do not
> need to be included in the base backup (David Steele)
> </para>
> Does not seem necessary to add that in the release notes..
I was actually just about to respond about this one. This patch
implements the feature in pg_basebackup as well as documenting that it
does not need to be backed up.
I think it should be combined with this item:
Exclude unlogged and temporary tables from streaming base backups
Sometime like:
Exclude unlogged and temporary tables and pg_internal.init from
streaming base backups
Thanks,
--
-David
david@pgmasters.net
Attachments:
signature.asc (application/pgp-signature, 873B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 11:47 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Andrew Dunstan @ 2018-05-14 11:47 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; Peter Geoghegan <pg@bowt.ie>; +Cc: Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 05/12/2018 08:47 PM, Bruce Momjian wrote:
> On Sat, May 12, 2018 at 01:22:55PM -0700, Peter Geoghegan wrote:
>> On Fri, May 11, 2018 at 2:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>> Done and URL updated.
>> I have some feedback on "Allow NOT NULL to be added to columns without
>> requiring a table rewrite". I suggest that this be phrased as "Avoid a
>> table rewrite when ALTER TABLE ADD COLUMN sets a default value for a
>> column". Referencing the fact that Postgres was previously able to do
>> this with a NULL default doesn't seem to add anything.
> Agreed, done:
>
> Allow <command>ALTER TABLE</command> to add a non-null default
> column without a table rewrite (Andrew Dunstan, Serge Rielau)
>
I think "a column with a non-null default" would be a bit clearer than
"a non-null default column".
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 12:04 Dilip Kumar <dilipbalaut@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Dilip Kumar @ 2018-05-14 12:04 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
>
> On a personal note, I want to apologize for not adequately championing
> two features that I think have strategic significance but didn't make it
> into Postgres 11: parallel FDW access and improved multi-variate
> statistics. I hope to do better job during Postgres 12.
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + As you are, so once was I. As I am, so you will be. +
> + Ancient Roman grave inscription +
>
>
I think the below commit is missed in the release notes?
5edc63bda68a77c4d38f0cbeae1c4271f9ef4100
Committer: Robert Haas <rhaas@postgresql.org> 2017-11-10 13:50:50
Account for the effect of lossy pages when costing bitmap scans.
Dilip Kumar, reviewed by Alexander Kumenkov, Amul Sul, and me.
Some final adjustments by me.
As part of this commit, we are also accounting for the lossy pages during
bitmap costing. This will consider
the effect of work_mem while selecting the bitmap heap scan path.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:04 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:04 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 03:43:08PM +0900, Michael Paquier wrote:
> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version
> > here:
>
> Thanks for gathering all the commits in one piece, Bruce.
>
> > I expect a torrent of feedback. ;-)
>
> I looked at the entries where my name shows up. Here is some feedback
> with HEAD at 8c6227a2 (latest as of writing this message).
>
> <para>
> Add information_schema columns related to table constraints and
> triggers (Michael Paquier)
> </para>
> The author of this entry is Peter Eisentraut, not me.
Thanks, I got "Reviewed-by" and "Author" mixed up.
> <para>
> Channel binding requires the server end
> of the <acronym>TLS</acronym> connection to
> prove that it knows the password. The options are <link
> linkend="libpq-scram-channel-binding"><option>scram_channel_binding=tls-unique</option></link>
> and <option>scram_channel_binding=tls-server-end-point</option>.
> </para>
> This is not actually correct. Channel binding is an MITM prevention
> mechanism which makes sure that after the SSL handshake the backend and
> the frontend are still connected to the same things. "tls-unique" makes
> sure that a connection is uniquely used using a hash of the TLS finish
> message, and end-point makes sure that the endpoints are the same using
> a hash of the server certificate.
So, channel binding has had me confused since I first heard about it. I
have done some research and reworded the commit with the attached first patch.
Also, I have created a second patch which actually explains the two
SCRAM channel binding options and how the work.
One question I do have is how do we prevent a fake server in the middle
from pretending it is a PG 10 server and therefore avoiding channel
binding protections? I don't see any channel binding options in
pg_hba.conf, and while libpq has options, they are explained with "This
parameter is mainly intended for protocol testing."
> <para>
> WHAT DOES THIS DOC TEXT MEAN? "An empty value specifies that
> the client will not use channel binding. The default value
> is tls-unique."
> </para>
> This means that the client can choose to not use channel binding (which
> sends a 'n' flag if you refer to the communication protocol of SCRAM),
> even if the server has advertised to the client channel binding. So
> this provides a way to disable the feature at will, an on/off switch if
> you want. If a v10 libpq tries to connect to a v11 server, then it
> won't use channel binding automatically. That may be worth adding to
> the documentation as well.
I have updated the docs in the second patch to explain this.
> <para>
> Allow access to file system functions to be controlled by
> <command>GRANT</command>/<command>REVOKE</command> permissions,
> rather than super-user checks (Michael Paquier)
> </para>
> Author is Stephen Frost here.
Done.
> <para>
> Use <command>GRANT</command>/<command>REVOKE</command>
> to control access to <link
> linkend="lo-import"><function>lo_import()</function></link>
> and <function>lo_export()</function> (Michael Paquier)
> </para>
> Tom Lane is a co-author here I think.
Done.
> <para>
> Add libpq parameter to allow physical and logical replication
> connections (Michael Paquier)
> </para>
> This commit has just added documentation which was missing and
> incomplete. I would suggest to remove it from the release notes as no
> new feature has been added.
Removed.
> <para>
> Add <link
> linkend="app-pgreceivewal"><application>pg_receivewal</application></link>
> option <option>--no-sync</option> to prevent synchronous
> <acronym>WAL</acronym> writes (Michael Paquier)
> </para>
> Perhaps this should be rewritten? --no-sync just disables any fsync
> calls for WAL segments, which is useful for tests, not recommended for
> production environments.
Done.
> <para>
> Prevent <application>pg_rewind</application> from running as
> <literal>root</literal> (Magnus Hagander)
> </para>
> This one's authorship is actually mine, after a bug I found :)
Done, thanks much.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachments: download all (2 files, .tar.gz)
pg11.diff (text/x-diff, 5.0K) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
new file mode 100644
index 6bde17e..763a154
*** a/doc/src/sgml/release-11.sgml
--- b/doc/src/sgml/release-11.sgml
*************** same commits as above
*** 1057,1063 ****
<para>
Add information_schema columns related to table constraints and
! triggers (Michael Paquier)
</para>
<para>
--- 1057,1063 ----
<para>
Add information_schema columns related to table constraints and
! triggers (Peter Eisentraut)
</para>
<para>
*************** same commits as above
*** 1091,1111 ****
<para>
Add libpq option to support channel binding when using <link
linkend="auth-password"><acronym>SCRAM</acronym></link>
! authentication (Michael Paquier)
</para>
<para>
! Channel binding requires the server end
! of the <acronym>TLS</acronym> connection to
! prove that it knows the password. The options are <link
linkend="libpq-scram-channel-binding"><option>scram_channel_binding=tls-unique</option></link>
and <option>scram_channel_binding=tls-server-end-point</option>.
</para>
-
- <para>
- WHAT DOES THIS DOC TEXT MEAN? "An empty value specifies that
- the client will not use channel binding. The default value
- is tls-unique."
</para>
</listitem>
--- 1091,1107 ----
<para>
Add libpq option to support channel binding when using <link
linkend="auth-password"><acronym>SCRAM</acronym></link>
! authentication (Peter Eisentraut)
</para>
<para>
! While <acronym>SCRAM</acronym> always prevents the
! replay of transmitted hashed passwords in a later
! session, <acronym>SCRAM</acronym> with channel binding
! also prevents man-in-the-middle attacks. The options are <link
linkend="libpq-scram-channel-binding"><option>scram_channel_binding=tls-unique</option></link>
and <option>scram_channel_binding=tls-server-end-point</option>.
</para>
</para>
</listitem>
*************** same commits as above
*** 1196,1202 ****
<para>
Allow access to file system functions to be controlled by
<command>GRANT</command>/<command>REVOKE</command> permissions,
! rather than super-user checks (Michael Paquier)
</para>
<para>
--- 1192,1198 ----
<para>
Allow access to file system functions to be controlled by
<command>GRANT</command>/<command>REVOKE</command> permissions,
! rather than super-user checks (Stephen Frost)
</para>
<para>
*************** same commits as above
*** 1218,1224 ****
Use <command>GRANT</command>/<command>REVOKE</command>
to control access to <link
linkend="lo-import"><function>lo_import()</function></link>
! and <function>lo_export()</function> (Michael Paquier)
</para>
<para>
--- 1214,1220 ----
Use <command>GRANT</command>/<command>REVOKE</command>
to control access to <link
linkend="lo-import"><function>lo_import()</function></link>
! and <function>lo_export()</function> (Michael Paquier, Tom Lane)
</para>
<para>
*************** same commits as above
*** 1881,1902 ****
<listitem>
<!--
- 2018-03-06 [0c2c81b40] doc: Add replication parameter to libpq documentation
- -->
-
- <para>
- Add libpq parameter to allow physical and logical replication
- connections (Michael Paquier)
- </para>
-
- <para>
- The libpq connection parameter is called <link
- linkend="libpq-connect-replication"><option>replication</option></link>.
- </para>
- </listitem>
-
- <listitem>
- <!--
2018-03-17 [e3bdb2d92] Set libpq sslcompression to off by default
-->
--- 1877,1882 ----
*************** same commits as above
*** 2330,2336 ****
Add <link
linkend="app-pgreceivewal"><application>pg_receivewal</application></link>
option <option>--no-sync</option> to prevent synchronous
! <acronym>WAL</acronym> writes (Michael Paquier)
</para>
</listitem>
--- 2310,2316 ----
Add <link
linkend="app-pgreceivewal"><application>pg_receivewal</application></link>
option <option>--no-sync</option> to prevent synchronous
! <acronym>WAL</acronym> writes, for testing (Michael Paquier)
</para>
</listitem>
*************** same commits as above
*** 2382,2388 ****
<para>
Prevent <application>pg_rewind</application> from running as
! <literal>root</literal> (Magnus Hagander)
</para>
</listitem>
--- 2362,2368 ----
<para>
Prevent <application>pg_rewind</application> from running as
! <literal>root</literal> (Michael Paquier)
</para>
</listitem>
binding.diff (text/x-diff, 3.7K) download
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
new file mode 100644
index 800e68a..498b8df
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** postgresql://%2Fvar%2Flib%2Fpostgresql/d
*** 1242,1255 ****
<term><literal>scram_channel_binding</literal></term>
<listitem>
<para>
! Specifies the channel binding type to use with SCRAM authentication.
! The list of channel binding types supported by server are listed in
! <xref linkend="sasl-authentication"/>. An empty value specifies that
! the client will not use channel binding. The default value is
! <literal>tls-unique</literal>.
</para>
<para>
Channel binding is only supported on SSL connections. If the
connection is not using SSL, then this setting is ignored.
</para>
--- 1242,1259 ----
<term><literal>scram_channel_binding</literal></term>
<listitem>
<para>
! Specifies the channel binding type to use with SCRAM
! authentication. While <acronym>SCRAM</acronym> alone prevents
! the replay of transmitted hashed passwords, channel binding also
! prevents man-in-the-middle attacks.
</para>
<para>
+ The list of channel binding types supported by the server are
+ listed in <xref linkend="sasl-authentication"/>. An empty value
+ specifies that the client will not use channel binding. If this
+ parameter is not specified, <literal>tls-unique</literal> is used,
+ if supported by both server and client.
Channel binding is only supported on SSL connections. If the
connection is not using SSL, then this setting is ignored.
</para>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
new file mode 100644
index 004b360..cfc805f
*** a/doc/src/sgml/protocol.sgml
--- b/doc/src/sgml/protocol.sgml
*************** should use <literal>tls-unique</literal>
*** 1584,1589 ****
--- 1584,1616 ----
that cannot support <literal>tls-unique</literal> for some reason.
</para>
+ <para>
+ In <acronym>SCRAM</acronym> without channel binding, the server chooses
+ a random number that is transmitted to the client to be mixed with the
+ user-supplied password in the transmitted password hash. While this
+ prevents the password hash from being successfully retransmitted in
+ a later session, it does not prevent a fake server between the real
+ server and client from passing through the server's random value
+ and successfully authenticating.
+ </para>
+
+ <para>
+ <acronym>SCRAM</acronym> with channel binding prevents such
+ man-in-the-middle attacks by mixing a value into the transmitted
+ password hash that cannot be retransmitted by a fake server.
+ In <acronym>SCRAM</acronym> with <literal>tls-unique</literal>
+ channel binding, the shared secret negotiated during the SSL session
+ is mixed into the user-supplied password hash. The shared secret
+ is partly chosen by the server, but not directly transmitted, making
+ it impossible for a fake server to create an SSL connection with the
+ client that has the same shared secret it has with the real server.
+ <acronym>SCRAM</acronym> with <literal>tls-server-end-point</literal>
+ mixes a hash of the server's certificate into the user-supplied password
+ hash. While a fake server can retransmit the real server's certificate,
+ it doesn't have access to the private key matching that certificate, and
+ therefore cannot prove it is the owner, causing SSL connection failure.
+ </para>
+
<procedure>
<title>Example</title>
<step id="scram-begin">
* Re: Postgres 11 release notes
@ 2018-05-14 20:08 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:08 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 14, 2018 at 09:26:07AM +0900, Michael Paquier wrote:
> On Sun, May 13, 2018 at 03:43:08PM +0900, Michael Paquier wrote:
> > On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > > I have committed the first draft of the Postgres 11 release notes. I
> > > will add more markup soon. You can view the most current version
> > > here:
> >
> > Thanks for gathering all the commits in one piece, Bruce.
> >
> > > I expect a torrent of feedback. ;-)
> >
> > I looked at the entries where my name shows up. Here is some feedback
> > with HEAD at 8c6227a2 (latest as of writing this message).
>
> A couple of extra notes while reading the HTML notes:
>
> <para>
> Add timeline information to the <link
> linkend="backup-lowlevel-base-backup"><filename>backup_label</filename></link>
> file (Simon Riggs)
> </para>
> This feature has been implemented by me, not Simon.
OK, fixed.
> <para>
> Document that <filename>pg_internal.init</filename> files do not
> need to be included in the base backup (David Steele)
> </para>
> Does not seem necessary to add that in the release notes..
Uh, I am not sure how people would hear about this information if we
don't have it in the release notes.
> <para>
> Cause large object permission checks
> to happen on large object open, <link
> linkend="lo-open"><function>lo_open()</function></link>, not
> read/write (Tom Lane)
> </para>
> Co-authoring with Tom on this one.
Fixed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:10 Bruce Momjian <bruce@momjian.us>
parent: David Steele <david@pgmasters.net>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:10 UTC (permalink / raw)
To: David Steele <david@pgmasters.net>; +Cc: Michael Paquier <michael@paquier.xyz>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 14, 2018 at 07:10:18AM -0400, David Steele wrote:
> On 5/13/18 8:26 PM, Michael Paquier wrote:
> > On Sun, May 13, 2018 at 03:43:08PM +0900, Michael Paquier wrote:
> >> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> >>> I have committed the first draft of the Postgres 11 release notes. I
> >>> will add more markup soon. You can view the most current version
> >>> here:
> >>
> >> Thanks for gathering all the commits in one piece, Bruce.
> >>
> >>> I expect a torrent of feedback. ;-)
> >>
> >> I looked at the entries where my name shows up. Here is some feedback
> >> with HEAD at 8c6227a2 (latest as of writing this message).
> >
> > <para>
> > Document that <filename>pg_internal.init</filename> files do not
> > need to be included in the base backup (David Steele)
> > </para>
> > Does not seem necessary to add that in the release notes..
>
> I was actually just about to respond about this one. This patch
> implements the feature in pg_basebackup as well as documenting that it
> does not need to be backed up.
>
> I think it should be combined with this item:
>
> Exclude unlogged and temporary tables from streaming base backups
>
> Sometime like:
>
> Exclude unlogged and temporary tables and pg_internal.init from
> streaming base backups
Good idea, done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:28 Bruce Momjian <bruce@momjian.us>
parent: Đặng Minh Hướng <kakalot49@gmail.com>
0 siblings, 2 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:28 UTC (permalink / raw)
To: Đặng Minh Hướng <kakalot49@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 05:43:25PM +0900, Đặng Minh Hướng wrote:
> Hello Bruce,
>
> Thanks for the greate work!
>
> 2018-05-12 0:08 GMT+09:00 Bruce Momjian <bruce@momjian.us>:
>
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
>
>
> I think the behavior change (from PostgreSQL 11) of power() with NaN below also
> need to report to users as the major change.
>
> related commit: 61b200e2f582d0886d9de947e182483339d881fd
> 6bdf1303b34bc630e8945ae3407ec7e8395c8fe5
>
> Discussion: https://postgr.es/m/
> 75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
Wow, that is an interesting case. The patch was applied to head and
backbranches, (so I didn't see it) but three days later reverted in back
branches, and after my date cut-off:
commit f74d83b3034f830bd68489b4aba99a4dee29c565
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed May 2 17:32:40 2018 -0400
Revert back-branch changes in power()'s behavior for NaN inputs.
Per discussion, the value of fixing these bugs in the back branches
doesn't outweigh the downsides of changing corner-case behavior in
a minor release. Hence, revert commits 217d8f3a1 and 4d864de48 in
the v10 branch and the corresponding commits in 9.3-9.6.
Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
Added:
Consistently return <literal>NaN</literal> for
<literal>NaN</literal> inputs to <function>power()</literal>
on older platforms (Dang Minh Huong)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:30 Bruce Momjian <bruce@momjian.us>
parent: Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:30 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 06:53:26PM +0900, Amit Langote wrote:
> On Sat, May 12, 2018 at 12:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
>
> Thank you for compiling this, Bruce!
>
> > I expect a torrent of feedback. ;-)
>
> The following item
>
> +<!--
> +2017-11-23 [05b6ec39d] Show partition info from psql \d+
> +-->
> +
> + <para>
> + Have psql \d+ show a partition count of zero (Amit Langote)
> + </para>
>
> missed mentioning Ashutosh Bapat as an author.
Added.
> Maybe, the item name and description text could be improved as follows:
>
> + <para>
> + Have psql \d+ always show the partition information (Amit
> Langote, Ashutosh Bapat)
> + </para>
> +
> + <para>
> + Previously partition information would not be displayed for a
> partitioned table if
> + it had no partitions. Also indicate which partitions are
> themselves partitioned.
> + </para>
I like it, done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:35 Bruce Momjian <bruce@momjian.us>
parent: Amit Kapila <amit.kapila16@gmail.com>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:35 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 04:40:19PM +0530, Amit Kapila wrote:
> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> > I expect a torrent of feedback. ;-)
> >
>
> Thanks for compiling the first draft. I think there are few things
> which we should add to the Parallel Queries section. (a) commit
> e89a71fb449af2ef74f47be1175f99956cf21524 -
> Pass InitPlan values to workers via Gather (Merge). We can write
> something like "Allow the part of the plan that references an initplan
> to run in parallel" or "Parallelise queries containing initplans",
Uh, I need some explaination of what an initplan is and what type of
query this helps.
> (b) "Parallelise queries that contains expensive functions in target
> lists" (Commits - 3f90ec8597c3515e0d3190613b31491686027e4b and
> 11cf92f6e2e13c0a6e3f98be3e629e6bd90b74d5).
So we generate the entire query before the target list function calls,
the run another parallel run just for those function calls? Really? Do
we run each column in its own worker or do we split the result set into
parts and run those in parallel? How do we know, just the function call
costs? I can admit I never saw that coming.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:36 Bruce Momjian <bruce@momjian.us>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:36 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sun, May 13, 2018 at 04:55:35PM +0530, Amit Kapila wrote:
> On Sun, May 13, 2018 at 4:40 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> I have committed the first draft of the Postgres 11 release notes. I
> >> will add more markup soon. You can view the most current version here:
> >>
> >> http://momjian.us/pgsql_docs/release-11.html
> >>
> >> I expect a torrent of feedback. ;-)
> >>
> >
> > Thanks for compiling the first draft.
> >
>
> One more comment on below item:
>
> Allow entire hash index pages to be scanned (Ashutosh Sharma)
>
> Previously each hash index entry has to be locked and scanned separately.
>
> I think it is better to write the second line as "Previously for each
> hash index entry, we need to refind the scan position within the page
> and cuts down on lock/unlock traffic.".
Nice, done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:37 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:37 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Peter Geoghegan <pg@bowt.ie>; Teodor Sigaev <teodor@sigaev.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 14, 2018 at 07:47:54AM -0400, Andrew Dunstan wrote:
>
>
> On 05/12/2018 08:47 PM, Bruce Momjian wrote:
> > On Sat, May 12, 2018 at 01:22:55PM -0700, Peter Geoghegan wrote:
> >> On Fri, May 11, 2018 at 2:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >>> Done and URL updated.
> >> I have some feedback on "Allow NOT NULL to be added to columns without
> >> requiring a table rewrite". I suggest that this be phrased as "Avoid a
> >> table rewrite when ALTER TABLE ADD COLUMN sets a default value for a
> >> column". Referencing the fact that Postgres was previously able to do
> >> this with a NULL default doesn't seem to add anything.
> > Agreed, done:
> >
> > Allow <command>ALTER TABLE</command> to add a non-null default
> > column without a table rewrite (Andrew Dunstan, Serge Rielau)
> >
>
>
> I think "a column with a non-null default" would be a bit clearer than
> "a non-null default column".
Yeah, I didn't like what I had either, so I changed it to what you
suggested, though it gives us an odd "with X, without Y" pattern:
Allow <command>ALTER TABLE</command> to add a column with
a non-null default without a table rewrite (Andrew Dunstan,
Serge Rielau)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 20:41 Bruce Momjian <bruce@momjian.us>
parent: Dilip Kumar <dilipbalaut@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-14 20:41 UTC (permalink / raw)
To: Dilip Kumar <dilipbalaut@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 14, 2018 at 05:34:54PM +0530, Dilip Kumar wrote:
>
> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
>
> On a personal note, I want to apologize for not adequately championing
> two features that I think have strategic significance but didn't make it
> into Postgres 11: parallel FDW access and improved multi-variate
> statistics. I hope to do better job during Postgres 12.
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + As you are, so once was I. As I am, so you will be. +
> + Ancient Roman grave inscription +
>
>
>
> I think the below commit is missed in the release notes?
>
> 5edc63bda68a77c4d38f0cbeae1c4271f9ef4100
>
> Committer: Robert Haas <rhaas@postgresql.org> 2017-11-10 13:50:50
>
> Account for the effect of lossy pages when costing bitmap scans.
>
> Dilip Kumar, reviewed by Alexander Kumenkov, Amul Sul, and me.
> Some final adjustments by me.
>
> As part of this commit, we are also accounting for the lossy pages during
> bitmap costing. This will consider
> the effect of work_mem while selecting the bitmap heap scan path.
Uh, that seems very exotic to mention, sorry. Others have opinions?
I have updated the PG11 doc URL with all the changes so far.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-14 23:10 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Michael Paquier @ 2018-05-14 23:10 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 14, 2018 at 04:04:58PM -0400, Bruce Momjian wrote:
> So, channel binding has had me confused since I first heard about it. I
> have done some research and reworded the commit with the attached
> first patch.
pg11.diff looks roughly fine to me.
> Also, I have created a second patch which actually explains the two
> SCRAM channel binding options and how the work.
+ The list of channel binding types supported by the server are
+ listed in <xref linkend="sasl-authentication"/>. An empty value
+ specifies that the client will not use channel binding. If this
+ parameter is not specified, <literal>tls-unique</literal> is used,
+ if supported by both server and client.
OK, that's simple enough for users, and we talk about the libpq
parameter here.
The second paragraph is also a nice addition. You really looked at this
stuff!
> One question I do have is how do we prevent a fake server in the middle
> from pretending it is a PG 10 server and therefore avoiding channel
> binding protections? I don't see any channel binding options in
> pg_hba.conf, and while libpq has options, they are explained with "This
> parameter is mainly intended for protocol testing."
The answer is that you cannot do that now, as much as you cannot have a
client forbid connection attempt if the client requests SCRAM but the
server downgrades to MD5. I had a topic on the matter at an unconf
session at the last PGAsia, and except for administrators which forgot
to upgrade a set of servers that was not something worth complicating
the code for, at least that's the conclusion which came out of the
session. At the end, this is not actually something that you would
control from the server if you care about security, but something which
is controlled from the client. The limitations that we have know are
partially due to the way libpq handles the authentication protocol.
Hence if you want to prevent servers attempting to do downgrades, you
need options like sslmode saying those things from the client point of
view:
- I want SCRAM, but refuse connection request if server attempts MD5 or
something else.
- I want SCRAM and channel binding, but refuse connection request if
server does not advertise channel binding to the client.
There may be value to an server side parameter which forces clients to
use channel binding even if the server has advertized the channel
binding SASL mechanism, and even if connection is made with SSL, but
that's not a downgrade-attack prevention.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 00:19 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-15 00:19 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: pgsql-hackers@postgresql.org
Hi Bruce,
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
I could not find this:
$ git log -1 f8e5f15
commit f8e5f156b30efee5d0038b03e38735773abcb7ed
Author: Andres Freund <andres@anarazel.de>
Date: Mon Sep 18 19:36:44 2017 -0700
Rearm statement_timeout after each executed query.
Previously statement_timeout, in the extended protocol, affected all
messages till a Sync message. For clients that pipeline/batch query
execution that's problematic.
Instead disable timeout after each Execute message, and enable, if
necessary, the timer in start_xact_command(). As that's done only for
Execute and not Parse / Bind, pipelining the latter two could still
cause undesirable timeouts. But a survey of protocol implementations
shows that all drivers issue Sync messages when preparing, and adding
timeout rearming to both is fairly expensive for the common parse /
bind / execute sequence.
Author: Tatsuo Ishii, editorialized by Andres Freund
Reviewed-By: Takayuki Tsunakawa, Andres Freund
Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@sraoss.co.jp
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 00:45 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 00:45 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 08:10:20AM +0900, Michael Paquier wrote:
> On Mon, May 14, 2018 at 04:04:58PM -0400, Bruce Momjian wrote:
> > So, channel binding has had me confused since I first heard about it. I
> > have done some research and reworded the commit with the attached
> > first patch.
>
> pg11.diff looks roughly fine to me.
>
> > Also, I have created a second patch which actually explains the two
> > SCRAM channel binding options and how the work.
>
> + The list of channel binding types supported by the server are
> + listed in <xref linkend="sasl-authentication"/>. An empty value
> + specifies that the client will not use channel binding. If this
> + parameter is not specified, <literal>tls-unique</literal> is used,
> + if supported by both server and client.
>
> OK, that's simple enough for users, and we talk about the libpq
> parameter here.
Great, committed.
> The second paragraph is also a nice addition. You really looked at this
> stuff!
Committed too.
Yeah, it bugs me when I hear terms thrown around but can't get to the
details of what is happening. This PDF unlocked it for me:
http://www.manulis.eu/papers/MaStDe_SSR14.pdf
> > One question I do have is how do we prevent a fake server in the middle
> > from pretending it is a PG 10 server and therefore avoiding channel
> > binding protections? I don't see any channel binding options in
> > pg_hba.conf, and while libpq has options, they are explained with "This
> > parameter is mainly intended for protocol testing."
>
> The answer is that you cannot do that now, as much as you cannot have a
> client forbid connection attempt if the client requests SCRAM but the
> server downgrades to MD5. I had a topic on the matter at an unconf
> session at the last PGAsia, and except for administrators which forgot
> to upgrade a set of servers that was not something worth complicating
> the code for, at least that's the conclusion which came out of the
> session. At the end, this is not actually something that you would
> control from the server if you care about security, but something which
> is controlled from the client. The limitations that we have know are
> partially due to the way libpq handles the authentication protocol.
> Hence if you want to prevent servers attempting to do downgrades, you
> need options like sslmode saying those things from the client point of
> view:
> - I want SCRAM, but refuse connection request if server attempts MD5 or
> something else.
> - I want SCRAM and channel binding, but refuse connection request if
> server does not advertise channel binding to the client.
Agreed. The libpq parameters don't help, I assume.
> There may be value to an server side parameter which forces clients to
> use channel binding even if the server has advertised the channel
> binding SASL mechanism, and even if connection is made with SSL, but
> that's not a downgrade-attack prevention.
What TLS does is to mix the offered ciphers into the negotiation hash so
a man-in-the-middle can't pretend it doesn't support something. Could
we do something like that here?
I have to question the value of man-in-the-middle protection that is so
easily bypassed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 00:46 Bruce Momjian <bruce@momjian.us>
parent: Tatsuo Ishii <ishii@sraoss.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 00:46 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@sraoss.co.jp>; +Cc: pgsql-hackers@postgresql.org
On Tue, May 15, 2018 at 09:19:04AM +0900, Tatsuo Ishii wrote:
> Hi Bruce,
>
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> > I expect a torrent of feedback. ;-)
>
> I could not find this:
>
> $ git log -1 f8e5f15
> commit f8e5f156b30efee5d0038b03e38735773abcb7ed
> Author: Andres Freund <andres@anarazel.de>
> Date: Mon Sep 18 19:36:44 2017 -0700
>
> Rearm statement_timeout after each executed query.
>
> Previously statement_timeout, in the extended protocol, affected all
> messages till a Sync message. For clients that pipeline/batch query
> execution that's problematic.
>
> Instead disable timeout after each Execute message, and enable, if
> necessary, the timer in start_xact_command(). As that's done only for
> Execute and not Parse / Bind, pipelining the latter two could still
> cause undesirable timeouts. But a survey of protocol implementations
> shows that all drivers issue Sync messages when preparing, and adding
> timeout rearming to both is fairly expensive for the common parse /
> bind / execute sequence.
>
> Author: Tatsuo Ishii, editorialized by Andres Freund
> Reviewed-By: Takayuki Tsunakawa, Andres Freund
> Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@sraoss.co.jp
That seemed too detailed for the release notes. Is that wrong?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 00:51 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-15 00:51 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: ishii@sraoss.co.jp; pgsql-hackers@postgresql.org
>> I could not find this:
>>
>> $ git log -1 f8e5f15
>> commit f8e5f156b30efee5d0038b03e38735773abcb7ed
>> Author: Andres Freund <andres@anarazel.de>
>> Date: Mon Sep 18 19:36:44 2017 -0700
>>
>> Rearm statement_timeout after each executed query.
>>
>> Previously statement_timeout, in the extended protocol, affected all
>> messages till a Sync message. For clients that pipeline/batch query
>> execution that's problematic.
>>
>> Instead disable timeout after each Execute message, and enable, if
>> necessary, the timer in start_xact_command(). As that's done only for
>> Execute and not Parse / Bind, pipelining the latter two could still
>> cause undesirable timeouts. But a survey of protocol implementations
>> shows that all drivers issue Sync messages when preparing, and adding
>> timeout rearming to both is fairly expensive for the common parse /
>> bind / execute sequence.
>>
>> Author: Tatsuo Ishii, editorialized by Andres Freund
>> Reviewed-By: Takayuki Tsunakawa, Andres Freund
>> Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@sraoss.co.jp
>
> That seemed too detailed for the release notes. Is that wrong?
This commit gives user-visible changes to the statment timeout
behavior. So I think this should be added to the release notes.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 03:12 Dang Minh Huong <kakalot49@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 0 replies; 181+ messages in thread
From: Dang Minh Huong @ 2018-05-15 03:12 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
2018/05/15 5:28、Bruce Momjian <bruce@momjian.us>のメール:
> Added:
>
> Consistently return <literal>NaN</literal> for
> <literal>NaN</literal> inputs to <function>power()</literal>
> on older platforms (Dang Minh Huong)
Thank you.
Regards,
—-
Dang Minh Huong
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 03:15 Amit Kapila <amit.kapila16@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Kapila @ 2018-05-15 03:15 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 2:05 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Sun, May 13, 2018 at 04:40:19PM +0530, Amit Kapila wrote:
>> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> > I have committed the first draft of the Postgres 11 release notes. I
>> > will add more markup soon. You can view the most current version here:
>> >
>> > http://momjian.us/pgsql_docs/release-11.html
>> >
>> > I expect a torrent of feedback. ;-)
>> >
>>
>> Thanks for compiling the first draft. I think there are few things
>> which we should add to the Parallel Queries section. (a) commit
>> e89a71fb449af2ef74f47be1175f99956cf21524 -
>> Pass InitPlan values to workers via Gather (Merge). We can write
>> something like "Allow the part of the plan that references an initplan
>> to run in parallel" or "Parallelise queries containing initplans",
>
> Uh, I need some explaination of what an initplan is
>
See the below comment in the code:
" This module is concerned with executing SubPlan expression nodes,
which should not be confused with sub-SELECTs appearing in FROM.
SubPlans are divided into "initplans", which are those that need only
one evaluation per query (among other restrictions, this requires that
they don't use any direct correlation variables from the parent plan
level), and "regular" subplans, which are re-evaluated every time
their result is required.
> and what type of
> query this helps.
>
Serial-Plan
-----------------
postgres=# explain select * from t1 where t1.k=(select max(k) from t3);
QUERY PLAN
--------------------------------------------------------------------
Seq Scan on t1 (cost=35.51..71.01 rows=10 width=12)
Filter: (k = $0)
InitPlan 1 (returns $0)
-> Aggregate (cost=35.50..35.51 rows=1 width=4)
-> Seq Scan on t3 (cost=0.00..30.40 rows=2040 width=4)
(5 rows)
Parallel-Plan
--------------------
postgres=# explain select * from t1 where t1.k=(select max(k) from t3);
QUERY PLAN
---------------------------------------------------------------------------------------
Gather (cost=9.71..19.38 rows=2 width=12)
Workers Planned: 2
Params Evaluated: $1
InitPlan 1 (returns $1)
-> Finalize Aggregate (cost=9.70..9.71 rows=1 width=4)
-> Gather (cost=9.69..9.70 rows=2 width=4)
Workers Planned: 2
-> Partial Aggregate (cost=9.69..9.70 rows=1 width=4)
-> Parallel Seq Scan on t3 (cost=0.00..8.75
rows=375 width=4)
-> Parallel Seq Scan on t1 (cost=0.00..9.67 rows=1 width=12)
Filter: (k = $1)
(11 rows)
Here, you can observe that initplan itself gets parallelized and the
part of plan tree referring initplan also got parallelized.
The other example from regression test is:
explain (costs off)
select count(*) from tenk1
where tenk1.unique1 = (Select max(tenk2.unique1) from tenk2);
QUERY PLAN
------------------------------------------------------
Aggregate
InitPlan 1 (returns $2)
-> Finalize Aggregate
-> Gather
Workers Planned: 2
-> Partial Aggregate
-> Parallel Seq Scan on tenk2
-> Gather
Workers Planned: 4
Params Evaluated: $2
-> Parallel Seq Scan on tenk1
Filter: (unique1 = $2)
(12 rows)
I can share more examples if required.
>> (b) "Parallelise queries that contains expensive functions in target
>> lists" (Commits - 3f90ec8597c3515e0d3190613b31491686027e4b and
>> 11cf92f6e2e13c0a6e3f98be3e629e6bd90b74d5).
>
> So we generate the entire query before the target list function calls,
> the run another parallel run just for those function calls?
>
No, it is not like that. We divide the scan among workers and each
worker should perform projection of the rows it scanned (after
applying filter). Now, if the expensive functions are part of target
lists, then we can push the computation of expensive functions (as
part of target list) in workers which will divide the work.
> Really? Do
> we run each column in its own worker or do we split the result set into
> parts and run those in parallel? How do we know, just the function call
> costs?
>
The function's cost can be determined via pg_proc->procost. For this
particular case, you can refer the call graph -
create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
> I can admit I never saw that coming.
>
I think the use case becomes interesting with parallel query because
now you can divide such cost among workers.
Feel free to ask more questions if above doesn't clarify the usage of
these features.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 03:46 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Langote @ 2018-05-15 03:46 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; Amit Langote <amitlangote09@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018/05/15 5:30, Bruce Momjian wrote:
> On Sun, May 13, 2018 at 06:53:26PM +0900, Amit Langote wrote:
>> The following item
>>
>> +<!--
>> +2017-11-23 [05b6ec39d] Show partition info from psql \d+
>> +-->
>> +
>> + <para>
>> + Have psql \d+ show a partition count of zero (Amit Langote)
>> + </para>
>>
>> missed mentioning Ashutosh Bapat as an author.
>
> Added.
>
>> Maybe, the item name and description text could be improved as follows:
>>
>> + <para>
>> + Have psql \d+ always show the partition information (Amit
>> Langote, Ashutosh Bapat)
>> + </para>
>> +
>> + <para>
>> + Previously partition information would not be displayed for a
>> partitioned table if
>> + it had no partitions. Also indicate which partitions are
>> themselves partitioned.
>> + </para>
>
> I like it, done.
Thank you.
Regards,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 05:26 Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Etsuro Fujita @ 2018-05-15 05:26 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
(2018/05/12 0:08), Bruce Momjian wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
>
> On a personal note, I want to apologize for not adequately championing
> two features that I think have strategic significance but didn't make it
> into Postgres 11: parallel FDW access and improved multi-variate
> statistics. I hope to do better job during Postgres 12.
Thanks for compiling this, Bruce!
I found a copy-pasto in this:
Below you will find a detailed account of the changes between
<productname>PostgreSQL</productname> 10 and the previous major
release.
I think the PG version should be 11, not 10. Patch attached.
Best regards,
Etsuro Fujita
Attachments:
fix-copy-pasto-in-release-note-11.patch (text/x-diff, 506B) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 4b31b46..407c67b 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -345,7 +345,7 @@ Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
<para>
Below you will find a detailed account of the changes between
- <productname>PostgreSQL</productname> 10 and the previous major
+ <productname>PostgreSQL</productname> 11 and the previous major
release.
</para>
* Re: Postgres 11 release notes
@ 2018-05-15 06:00 David Rowley <david.rowley@2ndquadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 2 replies; 181+ messages in thread
From: David Rowley @ 2018-05-15 06:00 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Đặng Minh Hướng <kakalot49@gmail.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 15 May 2018 at 08:28, Bruce Momjian <bruce@momjian.us> wrote:
> Consistently return <literal>NaN</literal> for
> <literal>NaN</literal> inputs to <function>power()</literal>
> on older platforms (Dang Minh Huong)
While I'm not in favour of removing Dang's credit here, technically
this patch was Tom's. The code added in float.c by Dang's patch
(61b200e2f) was effectively reverted by 6bdf1303. Dang's regression
tests remain, so should also be credited along with Tom.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 06:13 David Rowley <david.rowley@2ndquadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: David Rowley @ 2018-05-15 06:13 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On 12 May 2018 at 03:08, Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
I wonder if 3cda10f41bfed -- "Use atomic ops to hand out pages to scan
in parallel scan." should be listed in the notes.
If so, I'd suggest something like:
Improve performance of Parallel Seq Scans with many parallel workers
(David Rowley).
I'd be more inclined to leave it off the notes if the improvement was
marginal, but it was a fairly considerable improvement, per my
benchmarks in [1].
[1] https://www.postgresql.org/message-id/CAKJS1f9tgsPhqBcoPjv9_KUPZvTLCZ4jy%3DB%3DbhqgaKn7cYzm-w@mail.g...
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* RE: Postgres 11 release notes
@ 2018-05-15 06:40 Huong Dangminh <huo-dangminh@ys.jp.nec.com>
parent: David Rowley <david.rowley@2ndquadrant.com>
1 sibling, 1 reply; 181+ messages in thread
From: Huong Dangminh @ 2018-05-15 06:40 UTC (permalink / raw)
To: David Rowley <david.rowley@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; Akio Iwaasa <aki-iwaasa@vt.jp.nec.com>
Hi,
> From: David Rowley [mailto:david.rowley@2ndquadrant.com]
> Sent: Tuesday, May 15, 2018 3:01 PM
> To: Bruce Momjian <bruce@momjian.us>
> Cc: Đặng Minh Hướng <kakalot49@gmail.com>; PostgreSQL-development
> <pgsql-hackers@postgresql.org>
> Subject: Re: Postgres 11 release notes
>
> On 15 May 2018 at 08:28, Bruce Momjian <bruce@momjian.us> wrote:
> > Consistently return <literal>NaN</literal> for
> > <literal>NaN</literal> inputs to <function>power()</literal>
> > on older platforms (Dang Minh Huong)
>
> While I'm not in favour of removing Dang's credit here, technically this
> patch was Tom's. The code added in float.c by Dang's patch
> (61b200e2f) was effectively reverted by 6bdf1303. Dang's regression tests
> remain, so should also be credited along with Tom.
Thanks David, I agreed.
Also 6bdf1303 should be included like below,
<!--
Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
+Branch: master [61b200e2f] Avoid wrong results for power() with NaN
-->
<para>
Consistently return <literal>NaN</literal> for
<literal>NaN</literal> inputs to <function>power()</function>
- on older platforms (Dang Minh Huong)
+ on older platforms (Tom Lane, Dang Minh Huong)
</para>
Thanks and best regards,
---
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 07:34 Amit Kapila <amit.kapila16@gmail.com>
parent: David Rowley <david.rowley@2ndquadrant.com>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Kapila @ 2018-05-15 07:34 UTC (permalink / raw)
To: David Rowley <david.rowley@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 11:43 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 12 May 2018 at 03:08, Bruce Momjian <bruce@momjian.us> wrote:
>> I have committed the first draft of the Postgres 11 release notes. I
>> will add more markup soon. You can view the most current version here:
>>
>> http://momjian.us/pgsql_docs/release-11.html
>>
>> I expect a torrent of feedback. ;-)
>
> I wonder if 3cda10f41bfed -- "Use atomic ops to hand out pages to scan
> in parallel scan." should be listed in the notes.
>
> If so, I'd suggest something like:
>
> Improve performance of Parallel Seq Scans with many parallel workers
> (David Rowley).
>
+1 to add this in Release Notes.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 14:01 Tom Lane <tgl@sss.pgh.pa.us>
parent: David Rowley <david.rowley@2ndquadrant.com>
1 sibling, 1 reply; 181+ messages in thread
From: Tom Lane @ 2018-05-15 14:01 UTC (permalink / raw)
To: David Rowley <david.rowley@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Đặng Minh Hướng <kakalot49@gmail.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 15 May 2018 at 08:28, Bruce Momjian <bruce@momjian.us> wrote:
>> Consistently return <literal>NaN</literal> for
>> <literal>NaN</literal> inputs to <function>power()</literal>
>> on older platforms (Dang Minh Huong)
> While I'm not in favour of removing Dang's credit here, technically
> this patch was Tom's. The code added in float.c by Dang's patch
> (61b200e2f) was effectively reverted by 6bdf1303. Dang's regression
> tests remain, so should also be credited along with Tom.
I'm not particularly fussed about getting credit for that. However,
looking again at how that patch series turned out --- ie, that
we ensured POSIX behavior for NaNs only in HEAD --- I wonder
whether we shouldn't do what was mentioned in the commit log for
6bdf1303, and teach numeric_pow() about these same special cases.
It seems like it would be more consistent to change both functions
for v11, rather than letting that other shoe drop in some future
major release.
regards, tom lane
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 18:47 Bruce Momjian <bruce@momjian.us>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 18:47 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:
> No, it is not like that. We divide the scan among workers and each
> worker should perform projection of the rows it scanned (after
> applying filter). Now, if the expensive functions are part of target
> lists, then we can push the computation of expensive functions (as
> part of target list) in workers which will divide the work.
>
> > Really? Do
> > we run each column in its own worker or do we split the result set into
> > parts and run those in parallel? How do we know, just the function call
> > costs?
> >
>
> The function's cost can be determined via pg_proc->procost. For this
> particular case, you can refer the call graph -
> create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
>
> > I can admit I never saw that coming.
> >
>
> I think the use case becomes interesting with parallel query because
> now you can divide such cost among workers.
>
> Feel free to ask more questions if above doesn't clarify the usage of
> these features.
OK, I have added the following release note item for both of these:
2017-11-16 [e89a71fb4] Pass InitPlan values to workers via Gather (Merge).
2018-03-29 [3f90ec859] Postpone generate_gather_paths for topmost scan/join rel
2018-03-29 [11cf92f6e] Rewrite the code that applies scan/join targets to paths
Allow single-evaluation queries, e.g. <literal>FROM</literal>
clause queries, and functions in the target list to be
parallelized (Amit Kapila, Robert Haas)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 19:04 David Rowley <david.rowley@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 181+ messages in thread
From: David Rowley @ 2018-05-15 19:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <bruce@momjian.us>; Đặng Minh Hướng <kakalot49@gmail.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 16 May 2018 at 02:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Rowley <david.rowley@2ndquadrant.com> writes:
>> While I'm not in favour of removing Dang's credit here, technically
>> this patch was Tom's. The code added in float.c by Dang's patch
>> (61b200e2f) was effectively reverted by 6bdf1303. Dang's regression
>> tests remain, so should also be credited along with Tom.
>
> I'm not particularly fussed about getting credit for that. However,
> looking again at how that patch series turned out --- ie, that
> we ensured POSIX behavior for NaNs only in HEAD --- I wonder
> whether we shouldn't do what was mentioned in the commit log for
> 6bdf1303, and teach numeric_pow() about these same special cases.
> It seems like it would be more consistent to change both functions
> for v11, rather than letting that other shoe drop in some future
> major release.
I'm inclined to agree. It's hard to imagine these two functions
behaving differently in regards to NaN input is useful to anyone.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 19:37 Bruce Momjian <bruce@momjian.us>
parent: Tatsuo Ishii <ishii@sraoss.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 19:37 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@sraoss.co.jp>; +Cc: pgsql-hackers@postgresql.org
On Tue, May 15, 2018 at 09:51:47AM +0900, Tatsuo Ishii wrote:
> >> I could not find this:
> >>
> >> $ git log -1 f8e5f15
> >> commit f8e5f156b30efee5d0038b03e38735773abcb7ed
> >> Author: Andres Freund <andres@anarazel.de>
> >> Date: Mon Sep 18 19:36:44 2017 -0700
> >>
> >> Rearm statement_timeout after each executed query.
> >>
> >> Previously statement_timeout, in the extended protocol, affected all
> >> messages till a Sync message. For clients that pipeline/batch query
> >> execution that's problematic.
> >>
> >> Instead disable timeout after each Execute message, and enable, if
> >> necessary, the timer in start_xact_command(). As that's done only for
> >> Execute and not Parse / Bind, pipelining the latter two could still
> >> cause undesirable timeouts. But a survey of protocol implementations
> >> shows that all drivers issue Sync messages when preparing, and adding
> >> timeout rearming to both is fairly expensive for the common parse /
> >> bind / execute sequence.
> >>
> >> Author: Tatsuo Ishii, editorialized by Andres Freund
> >> Reviewed-By: Takayuki Tsunakawa, Andres Freund
> >> Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@sraoss.co.jp
> >
> > That seemed too detailed for the release notes. Is that wrong?
>
> This commit gives user-visible changes to the statment timeout
> behavior. So I think this should be added to the release notes.
OK, makes sense. Here is what I added:
2017-09-18 [f8e5f156b] Rearm statement_timeout after each executed query.
In the <link linkend="protocol-query-concepts">Extended Query
Protocol</link>, have <varname>statement_timeout</varname> apply
to each <literal>Execute</literal> message, not to all commands
before <literal>Sync</literal> (Tatsuo Ishii)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 19:44 Bruce Momjian <bruce@momjian.us>
parent: Huong Dangminh <huo-dangminh@ys.jp.nec.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 19:44 UTC (permalink / raw)
To: Huong Dangminh <huo-dangminh@ys.jp.nec.com>; +Cc: David Rowley <david.rowley@2ndquadrant.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Akio Iwaasa <aki-iwaasa@vt.jp.nec.com>
On Tue, May 15, 2018 at 06:40:18AM +0000, Huong Dangminh wrote:
> Hi,
>
> > From: David Rowley [mailto:david.rowley@2ndquadrant.com]
> > Sent: Tuesday, May 15, 2018 3:01 PM
> > To: Bruce Momjian <bruce@momjian.us>
> > Cc: Đặng Minh Hướng <kakalot49@gmail.com>; PostgreSQL-development
> > <pgsql-hackers@postgresql.org>
> > Subject: Re: Postgres 11 release notes
> >
> > On 15 May 2018 at 08:28, Bruce Momjian <bruce@momjian.us> wrote:
> > > Consistently return <literal>NaN</literal> for
> > > <literal>NaN</literal> inputs to <function>power()</literal>
> > > on older platforms (Dang Minh Huong)
> >
> > While I'm not in favour of removing Dang's credit here, technically this
> > patch was Tom's. The code added in float.c by Dang's patch
> > (61b200e2f) was effectively reverted by 6bdf1303. Dang's regression tests
> > remain, so should also be credited along with Tom.
>
> Thanks David, I agreed.
> Also 6bdf1303 should be included like below,
>
> <!--
> Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
> +Branch: master [61b200e2f] Avoid wrong results for power() with NaN
> -->
>
> <para>
> Consistently return <literal>NaN</literal> for
> <literal>NaN</literal> inputs to <function>power()</function>
> - on older platforms (Dang Minh Huong)
> + on older platforms (Tom Lane, Dang Minh Huong)
> </para>
OK, changed, thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 19:45 Bruce Momjian <bruce@momjian.us>
parent: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 19:45 UTC (permalink / raw)
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 02:26:33PM +0900, Etsuro Fujita wrote:
> (2018/05/12 0:08), Bruce Momjian wrote:
> >I have committed the first draft of the Postgres 11 release notes. I
> >will add more markup soon. You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> >I expect a torrent of feedback. ;-)
> >
> >On a personal note, I want to apologize for not adequately championing
> >two features that I think have strategic significance but didn't make it
> >into Postgres 11: parallel FDW access and improved multi-variate
> >statistics. I hope to do better job during Postgres 12.
>
> Thanks for compiling this, Bruce!
>
> I found a copy-pasto in this:
>
> Below you will find a detailed account of the changes between
> <productname>PostgreSQL</productname> 10 and the previous major
> release.
>
> I think the PG version should be 11, not 10. Patch attached.
Ah, seems I missed that one, thanks.
---------------------------------------------------------------------------
>
> Best regards,
> Etsuro Fujita
> diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
> index 4b31b46..407c67b 100644
> --- a/doc/src/sgml/release-11.sgml
> +++ b/doc/src/sgml/release-11.sgml
> @@ -345,7 +345,7 @@ Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
>
> <para>
> Below you will find a detailed account of the changes between
> - <productname>PostgreSQL</productname> 10 and the previous major
> + <productname>PostgreSQL</productname> 11 and the previous major
> release.
> </para>
>
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 19:55 Bruce Momjian <bruce@momjian.us>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 19:55 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: David Rowley <david.rowley@2ndquadrant.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 01:04:55PM +0530, Amit Kapila wrote:
> On Tue, May 15, 2018 at 11:43 AM, David Rowley
> <david.rowley@2ndquadrant.com> wrote:
> > On 12 May 2018 at 03:08, Bruce Momjian <bruce@momjian.us> wrote:
> >> I have committed the first draft of the Postgres 11 release notes. I
> >> will add more markup soon. You can view the most current version here:
> >>
> >> http://momjian.us/pgsql_docs/release-11.html
> >>
> >> I expect a torrent of feedback. ;-)
> >
> > I wonder if 3cda10f41bfed -- "Use atomic ops to hand out pages to scan
> > in parallel scan." should be listed in the notes.
> >
> > If so, I'd suggest something like:
> >
> > Improve performance of Parallel Seq Scans with many parallel workers
> > (David Rowley).
> >
>
> +1 to add this in Release Notes.
Done, and URL updated with all confirmed changed. :-)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 21:11 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-15 21:11 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: pgsql-hackers@postgresql.org
>> This commit gives user-visible changes to the statment timeout
>> behavior. So I think this should be added to the release notes.
>
> OK, makes sense. Here is what I added:
>
> 2017-09-18 [f8e5f156b] Rearm statement_timeout after each executed query.
>
> In the <link linkend="protocol-query-concepts">Extended Query
> Protocol</link>, have <varname>statement_timeout</varname> apply
> to each <literal>Execute</literal> message, not to all commands
> before <literal>Sync</literal> (Tatsuo Ishii)
Can you please add Andres Freund to the author? He made extensive
changes to the original patch to improve it.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 23:12 Bruce Momjian <bruce@momjian.us>
parent: Tatsuo Ishii <ishii@sraoss.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 23:12 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@sraoss.co.jp>; +Cc: pgsql-hackers@postgresql.org
fOn Wed, May 16, 2018 at 06:11:52AM +0900, Tatsuo Ishii wrote:
> >> This commit gives user-visible changes to the statment timeout
> >> behavior. So I think this should be added to the release notes.
> >
> > OK, makes sense. Here is what I added:
> >
> > 2017-09-18 [f8e5f156b] Rearm statement_timeout after each executed query.
> >
> > In the <link linkend="protocol-query-concepts">Extended Query
> > Protocol</link>, have <varname>statement_timeout</varname> apply
> > to each <literal>Execute</literal> message, not to all commands
> > before <literal>Sync</literal> (Tatsuo Ishii)
>
> Can you please add Andres Freund to the author? He made extensive
> changes to the original patch to improve it.
Done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 23:31 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-15 23:31 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: ishii@sraoss.co.jp; pgsql-hackers@postgresql.org
>> Can you please add Andres Freund to the author? He made extensive
>> changes to the original patch to improve it.
>
> Done.
Thanks!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 23:33 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-15 23:33 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: pgsql-hackers@postgresql.org
> Change the ps process display labels to match the
> pg_stat_activity.backend_type labels (Peter Eisentraut)
pg_stat_activity.backend_type label for postgres process dedicated to
user sessions is "client backend" while ps still shows something like
"postgres: t-ishii postgres [local] idle". Do we want to mention this?
For example "Change the ps process display labels to match the
pg_stat_activity.backend_type labels except client backend (Peter
Eisentraut)"
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 23:37 Bruce Momjian <bruce@momjian.us>
parent: Tatsuo Ishii <ishii@sraoss.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 23:37 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@sraoss.co.jp>; +Cc: pgsql-hackers@postgresql.org
On Wed, May 16, 2018 at 08:33:53AM +0900, Tatsuo Ishii wrote:
> > Change the ps process display labels to match the
> > pg_stat_activity.backend_type labels (Peter Eisentraut)
>
> pg_stat_activity.backend_type label for postgres process dedicated to
> user sessions is "client backend" while ps still shows something like
> "postgres: t-ishii postgres [local] idle". Do we want to mention this?
>
> For example "Change the ps process display labels to match the
> pg_stat_activity.backend_type labels except client backend (Peter
> Eisentraut)"
Good point. Should we mention background workers instead?
Change the ps process display labels for background workers
to match the pg_stat_activity.backend_type labels Eisentraut)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 23:52 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-15 23:52 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: ishii@sraoss.co.jp; pgsql-hackers@postgresql.org
>> pg_stat_activity.backend_type label for postgres process dedicated to
>> user sessions is "client backend" while ps still shows something like
>> "postgres: t-ishii postgres [local] idle". Do we want to mention this?
>>
>> For example "Change the ps process display labels to match the
>> pg_stat_activity.backend_type labels except client backend (Peter
>> Eisentraut)"
>
> Good point. Should we mention background workers instead?
>
> Change the ps process display labels for background workers
> to match the pg_stat_activity.backend_type labels Eisentraut)
Seems good to me.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-15 23:57 Bruce Momjian <bruce@momjian.us>
parent: Tatsuo Ishii <ishii@sraoss.co.jp>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-15 23:57 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@sraoss.co.jp>; +Cc: pgsql-hackers@postgresql.org
On Wed, May 16, 2018 at 08:52:05AM +0900, Tatsuo Ishii wrote:
> >> pg_stat_activity.backend_type label for postgres process dedicated to
> >> user sessions is "client backend" while ps still shows something like
> >> "postgres: t-ishii postgres [local] idle". Do we want to mention this?
> >>
> >> For example "Change the ps process display labels to match the
> >> pg_stat_activity.backend_type labels except client backend (Peter
> >> Eisentraut)"
> >
> > Good point. Should we mention background workers instead?
> >
> > Change the ps process display labels for background workers
> > to match the pg_stat_activity.backend_type labels Eisentraut)
>
> Seems good to me.
Done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 00:01 Tatsuo Ishii <ishii@sraoss.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Tatsuo Ishii @ 2018-05-16 00:01 UTC (permalink / raw)
To: bruce@momjian.us; +Cc: pgsql-hackers@postgresql.org
There's a small typo.
> Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas Munro)
I think a space between "huge" and "(large)" is needed.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 00:03 Bruce Momjian <bruce@momjian.us>
parent: Tatsuo Ishii <ishii@sraoss.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-16 00:03 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@sraoss.co.jp>; +Cc: pgsql-hackers@postgresql.org
On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> There's a small typo.
>
> > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas Munro)
>
> I think a space between "huge" and "(large)" is needed.
Done, URL updated.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 04:22 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 181+ messages in thread
From: Michael Paquier @ 2018-05-16 04:22 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
> What TLS does is to mix the offered ciphers into the negotiation hash so
> a man-in-the-middle can't pretend it doesn't support something. Could
> we do something like that here?
I have to admit that I don't quite follow here, the shape of channel
binding data is decided by RFC 5929, so we need to stick with it.
> I have to question the value of man-in-the-middle protection that is so
> easily bypassed.
Well, the backend does its job, and answers based on what the client
wants to do. But what you are questioning here is the handling of
authentication downgrade attempts from a server by libpq, which is a
different problem, larger than just channel binding as it relates as
well to MD5/SCRAM interactions. For example, it is perfectly possible
to implement downgrade protections for any drivers which speak the
protocol, like JDBC, even with a v11 backend.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 04:25 Amit Kapila <amit.kapila16@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Kapila @ 2018-05-16 04:25 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 12:17 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:
>> No, it is not like that. We divide the scan among workers and each
>> worker should perform projection of the rows it scanned (after
>> applying filter). Now, if the expensive functions are part of target
>> lists, then we can push the computation of expensive functions (as
>> part of target list) in workers which will divide the work.
>>
>> > Really? Do
>> > we run each column in its own worker or do we split the result set into
>> > parts and run those in parallel? How do we know, just the function call
>> > costs?
>> >
>>
>> The function's cost can be determined via pg_proc->procost. For this
>> particular case, you can refer the call graph -
>> create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
>>
>> > I can admit I never saw that coming.
>> >
>>
>> I think the use case becomes interesting with parallel query because
>> now you can divide such cost among workers.
>>
>> Feel free to ask more questions if above doesn't clarify the usage of
>> these features.
>
> OK, I have added the following release note item for both of these:
>
> 2017-11-16 [e89a71fb4] Pass InitPlan values to workers via Gather (Merge).
> 2018-03-29 [3f90ec859] Postpone generate_gather_paths for topmost scan/join rel
> 2018-03-29 [11cf92f6e] Rewrite the code that applies scan/join targets to paths
>
> Allow single-evaluation queries, e.g. <literal>FROM</literal>
> clause queries, and functions in the target list to be
> parallelized (Amit Kapila, Robert Haas)
>
Sorry, but it is not clear to me what you intend to say by "e.g.
<literal>FROM</literal> clause queries"? What I could imagine is
something like "e.g. queries in <literal>WHERE</literal> clause that
return aggregate value"
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 09:30 Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Etsuro Fujita @ 2018-05-16 09:30 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
(2018/05/16 4:45), Bruce Momjian wrote:
> On Tue, May 15, 2018 at 02:26:33PM +0900, Etsuro Fujita wrote:
>> (2018/05/12 0:08), Bruce Momjian wrote:
>>> I have committed the first draft of the Postgres 11 release notes. I
>>> will add more markup soon. You can view the most current version here:
>>>
>>> http://momjian.us/pgsql_docs/release-11.html
>>>
>>> I expect a torrent of feedback. ;-)
>>>
>>> On a personal note, I want to apologize for not adequately championing
>>> two features that I think have strategic significance but didn't make it
>>> into Postgres 11: parallel FDW access and improved multi-variate
>>> statistics. I hope to do better job during Postgres 12.
>>
>> Thanks for compiling this, Bruce!
>>
>> I found a copy-pasto in this:
>>
>> Below you will find a detailed account of the changes between
>> <productname>PostgreSQL</productname> 10 and the previous major
>> release.
>>
>> I think the PG version should be 11, not 10. Patch attached.
>
> Ah, seems I missed that one, thanks.
Thank you.
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 10:09 Heikki Linnakangas <hlinnaka@iki.fi>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 181+ messages in thread
From: Heikki Linnakangas @ 2018-05-16 10:09 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On 16/05/18 07:22, Michael Paquier wrote:
> On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
>> What TLS does is to mix the offered ciphers into the negotiation hash so
>> a man-in-the-middle can't pretend it doesn't support something. Could
>> we do something like that here?
>
> I have to admit that I don't quite follow here, the shape of channel
> binding data is decided by RFC 5929, so we need to stick with it.
>
>> I have to question the value of man-in-the-middle protection that is so
>> easily bypassed.
>
> Well, the backend does its job, and answers based on what the client
> wants to do. But what you are questioning here is the handling of
> authentication downgrade attempts from a server by libpq, which is a
> different problem, larger than just channel binding as it relates as
> well to MD5/SCRAM interactions. For example, it is perfectly possible
> to implement downgrade protections for any drivers which speak the
> protocol, like JDBC, even with a v11 backend.
I have to agree with Bruce, that it's pretty useless to implement
channel binding, if there is no way to require it in libpq. IMHO that
must be fixed.
It's true that even if libpq doesn't implement it, other drivers like
JDBC could. Good for them, but that still sucks for libpq.
- Heikki
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 10:50 Heikki Linnakangas <hlinnaka@iki.fi>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Heikki Linnakangas @ 2018-05-16 10:50 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
> * Allow bytes to be specified for server variable sizes (Beena Emerson)
>
> The specification is "B".
I had to dig the commit in the git history to figure out what this is.
I'd suggest rewording this:
* Allow server options related to memory and file sizes, to be specified
as number of bytes.
The new unit is "B". This is in addition to "kB", "MB", "GB" and "TB",
which were accepted previously.
- Heikki
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 11:59 Michael Paquier <michael@paquier.xyz>
parent: Heikki Linnakangas <hlinnaka@iki.fi>
0 siblings, 1 reply; 181+ messages in thread
From: Michael Paquier @ 2018-05-16 11:59 UTC (permalink / raw)
To: Heikki Linnakangas <hlinnaka@iki.fi>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote:
> I have to agree with Bruce, that it's pretty useless to implement channel
> binding, if there is no way to require it in libpq. IMHO that must be
> fixed.
Wouldn't we want to also do something for the case where a client is
willing to use SCRAM but that the server forces back MD5? In which
case, one possibility is a connection parameter like the following,
named say authmethod:
- An empty value is equivalent to the current behavior, and is the
default.
- 'scram' means that client is willing to use SCRAM, which would cause a
failure if server attempts to enforce MD5.
- 'scram-plus' means that client enforces SCRAM and channel binding.
Or we could just have a channel_binding_mode, which has a "require"
value like sslmode, and "prefer" mode, which is the default and the
current behavior... Still what to do with MD5 requests in this case?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 14:08 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 181+ messages in thread
From: Alvaro Herrera @ 2018-05-16 14:08 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tatsuo Ishii <ishii@sraoss.co.jp>; pgsql-hackers@postgresql.org
On 2018-May-15, Bruce Momjian wrote:
> On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> > There's a small typo.
> >
> > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas Munro)
> >
> > I think a space between "huge" and "(large)" is needed.
>
> Done, URL updated.
I'm not sure why we say "huge (large) pages". The natural term for
Windows is "large-pages",
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs.85).aspx
so I think we should use that terminology. Maybe something like
Add support for <firstterm>large pages</firstterm> on Windows (Takayuki Tsunakawa, Thomas Munro)
This is controlled by the <link>huge_pages</link> configuration parameter.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 16:23 Magnus Hagander <magnus@hagander.net>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
1 sibling, 1 reply; 181+ messages in thread
From: Magnus Hagander @ 2018-05-16 16:23 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Tatsuo Ishii <ishii@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
> On 2018-May-15, Bruce Momjian wrote:
>
> > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> > > There's a small typo.
> > >
> > > > Add support for with huge(large) pages on Windows (Takayuki
> Tsunakawa, Thomas Munro)
> > >
> > > I think a space between "huge" and "(large)" is needed.
> >
> > Done, URL updated.
>
> I'm not sure why we say "huge (large) pages". The natural term for
> Windows is "large-pages",
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> aa366720(v=vs.85).aspx
> so I think we should use that terminology. Maybe something like
>
> Add support for <firstterm>large pages</firstterm> on Windows (Takayuki
> Tsunakawa, Thomas Munro)
> This is controlled by the <link>huge_pages</link> configuration parameter.
>
>
I assume the point here is that we the term huge pages is what's used in
PostgreSQL. For example, they are still configured using the huge_pages
GUC.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 16:24 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 181+ messages in thread
From: Alvaro Herrera @ 2018-05-16 16:24 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Bruce Momjian <bruce@momjian.us>; Tatsuo Ishii <ishii@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018-May-16, Magnus Hagander wrote:
> On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
> > I'm not sure why we say "huge (large) pages". The natural term for
> > Windows is "large-pages",
> > https://msdn.microsoft.com/en-us/library/windows/desktop/
> > aa366720(v=vs.85).aspx
> > so I think we should use that terminology. Maybe something like
> >
> > Add support for <firstterm>large pages</firstterm> on Windows (Takayuki
> > Tsunakawa, Thomas Munro)
> > This is controlled by the <link>huge_pages</link> configuration parameter.
>
> I assume the point here is that we the term huge pages is what's used
> in PostgreSQL. For example, they are still configured using the
> huge_pages GUC.
That's exactly what my proposed wording says :-)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-16 16:28 Magnus Hagander <magnus@hagander.net>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 0 replies; 181+ messages in thread
From: Magnus Hagander @ 2018-05-16 16:28 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Tatsuo Ishii <ishii@sraoss.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 6:24 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
> On 2018-May-16, Magnus Hagander wrote:
>
> > On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera <
> alvherre@2ndquadrant.com>
> > wrote:
>
> > > I'm not sure why we say "huge (large) pages". The natural term for
> > > Windows is "large-pages",
> > > https://msdn.microsoft.com/en-us/library/windows/desktop/
> > > aa366720(v=vs.85).aspx
> > > so I think we should use that terminology. Maybe something like
> > >
> > > Add support for <firstterm>large pages</firstterm> on Windows (Takayuki
> > > Tsunakawa, Thomas Munro)
> > > This is controlled by the <link>huge_pages</link> configuration
> parameter.
> >
> > I assume the point here is that we the term huge pages is what's used
> > in PostgreSQL. For example, they are still configured using the
> > huge_pages GUC.
>
> That's exactly what my proposed wording says :-)
>
>
Uh. Nevermind. Nothing to see here. For some reason I only saw the first
paragraph.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 00:13 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 00:13 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 01:22:45PM +0900, Michael Paquier wrote:
> On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote:
> > What TLS does is to mix the offered ciphers into the negotiation hash so
> > a man-in-the-middle can't pretend it doesn't support something. Could
> > we do something like that here?
>
> I have to admit that I don't quite follow here, the shape of channel
> binding data is decided by RFC 5929, so we need to stick with it.
OK, let me explain. First, there are two man-in-the-middle types of
attacks. The first one allows the two legitimate ends of the TLS
connection to negotiate the shared secret between themselves, but
injects or changes some of the packets before the shared secret is
agreed upon, perhaps to downgrade the strength of the protocol options.
TLS prevents this type of man-in-the-middle attack by hashing the shared
secret with a hash of all of the TLS negotiation messages previously
sent. Each side who knows the shared secret can verify that no messages
were changed; see:
https://security.stackexchange.com/questions/115284/how-can-an-attacker-downgrade-modify-the-cipher-...
The second type of man-in-the-middle attack is where the
man-in-the-middle is negotiating the shared secret separately with the
two end points. There is no way to detect this without having some
shared secret between the two valid end points. One shared secret is
the password hashed with the shared secret, which is what tls-unique
uses. The second uses the server certificate hashed with the shared
secret. This is now documented in Postgres:
In <acronym>SCRAM</acronym> with <literal>tls-unique</literal>
channel binding, the shared secret negotiated during the SSL session
is mixed into the user-supplied password hash. The shared secret
is partly chosen by the server, but not directly transmitted, making
it impossible for a fake server to create an SSL connection with the
client that has the same shared secret it has with the real server.
<acronym>SCRAM</acronym> with <literal>tls-server-end-point</literal>
mixes a hash of the server's certificate into the user-supplied password
hash. While a fake server can retransmit the real server's certificate,
it doesn't have access to the private key matching that certificate, and
therefore cannot prove it is the owner, causing SSL connection failure.
TLS prevents a man-in-the-middle from injecting invalid packets.
However, it does not prevent a man-in-the-middle attack with separeate
shared secret negotiation unless certificates are used.
The current problem under discussion is the same as that of the
man-in-the-middle packet change/injection attack in that the
man-in-the-middle can change the options reported as supported by the
Postgres server, before the password is sent. The most efficient fix
for this would be for the all Postgres protocol messages up to the point
where the authentication was chosen to be hashed with the password and
sent to the server. In that way, if a man-in-the-middle changed the
server-reported supported authentication, the server would identify this
and refuse the connection.
The problem is that current and past-version PG authentication methods
don't have any protocol downgrade protection, and it is hard to add it
unless you just remove support for old protocols. I think the only
reasonable solution is to allow the client and/or server to force
channel binding.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 00:20 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 00:20 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 08:59:23PM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote:
> > I have to agree with Bruce, that it's pretty useless to implement channel
> > binding, if there is no way to require it in libpq. IMHO that must be
> > fixed.
>
> Wouldn't we want to also do something for the case where a client is
> willing to use SCRAM but that the server forces back MD5? In which
> case, one possibility is a connection parameter like the following,
> named say authmethod:
> - An empty value is equivalent to the current behavior, and is the
> default.
> - 'scram' means that client is willing to use SCRAM, which would cause a
> failure if server attempts to enforce MD5.
> - 'scram-plus' means that client enforces SCRAM and channel binding.
>
> Or we could just have a channel_binding_mode, which has a "require"
> value like sslmode, and "prefer" mode, which is the default and the
> current behavior... Still what to do with MD5 requests in this case?
Just to reiterate, MD5 and SCRAM-less-binding is designed to avoid
packet _replay_. It assumes no man-in-the-middle has adjusted what is
supported by the two endpoints.
SCRAM-with-binding is the first password method that attempts to avoid
man-in-the-middle attacks, and therefore is much less likely to be able
to trust what the endpoints supports. I think it is really the
channel_binding_mode that we want to control at the client. The lesser
modes are much more reasonable to use an automatic best-supported
negotiation, which is what we do now.
FYI, I think the server could also require channel binding for SCRAM. We
already have scram-sha-256 in pg_hba.conf, and I think
scram-sha-256-plus would be reasonable.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 00:24 Bruce Momjian <bruce@momjian.us>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 00:24 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 09:55:05AM +0530, Amit Kapila wrote:
> On Wed, May 16, 2018 at 12:17 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:
> >> No, it is not like that. We divide the scan among workers and each
> >> worker should perform projection of the rows it scanned (after
> >> applying filter). Now, if the expensive functions are part of target
> >> lists, then we can push the computation of expensive functions (as
> >> part of target list) in workers which will divide the work.
> >>
> >> > Really? Do
> >> > we run each column in its own worker or do we split the result set into
> >> > parts and run those in parallel? How do we know, just the function call
> >> > costs?
> >> >
> >>
> >> The function's cost can be determined via pg_proc->procost. For this
> >> particular case, you can refer the call graph -
> >> create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
> >>
> >> > I can admit I never saw that coming.
> >> >
> >>
> >> I think the use case becomes interesting with parallel query because
> >> now you can divide such cost among workers.
> >>
> >> Feel free to ask more questions if above doesn't clarify the usage of
> >> these features.
> >
> > OK, I have added the following release note item for both of these:
> >
> > 2017-11-16 [e89a71fb4] Pass InitPlan values to workers via Gather (Merge).
> > 2018-03-29 [3f90ec859] Postpone generate_gather_paths for topmost scan/join rel
> > 2018-03-29 [11cf92f6e] Rewrite the code that applies scan/join targets to paths
> >
> > Allow single-evaluation queries, e.g. <literal>FROM</literal>
> > clause queries, and functions in the target list to be
> > parallelized (Amit Kapila, Robert Haas)
> >
>
> Sorry, but it is not clear to me what you intend to say by "e.g.
> <literal>FROM</literal> clause queries"? What I could imagine is
> something like "e.g. queries in <literal>WHERE</literal> clause that
> return aggregate value"
Oh, sorry, changed to:
Allow single-evaluation queries, e.g. <literal>WHERE</literal>
clause aggregate queries, and functions in the target list to be
parallelized (Amit Kapila, Robert Haas)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 00:26 Bruce Momjian <bruce@momjian.us>
parent: Heikki Linnakangas <hlinnaka@iki.fi>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 00:26 UTC (permalink / raw)
To: Heikki Linnakangas <hlinnaka@iki.fi>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 16, 2018 at 01:50:04PM +0300, Heikki Linnakangas wrote:
> >* Allow bytes to be specified for server variable sizes (Beena Emerson)
> >
> >The specification is "B".
>
> I had to dig the commit in the git history to figure out what this is. I'd
> suggest rewording this:
>
> * Allow server options related to memory and file sizes, to be specified as
> number of bytes.
>
> The new unit is "B". This is in addition to "kB", "MB", "GB" and "TB", which
> were accepted previously.
OK, good, done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 00:29 Bruce Momjian <bruce@momjian.us>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
1 sibling, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 00:29 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Tatsuo Ishii <ishii@sraoss.co.jp>; pgsql-hackers@postgresql.org
On Wed, May 16, 2018 at 10:08:18AM -0400, Alvaro Herrera wrote:
> On 2018-May-15, Bruce Momjian wrote:
>
> > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote:
> > > There's a small typo.
> > >
> > > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas Munro)
> > >
> > > I think a space between "huge" and "(large)" is needed.
> >
> > Done, URL updated.
>
> I'm not sure why we say "huge (large) pages". The natural term for
> Windows is "large-pages",
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs.85).aspx
> so I think we should use that terminology. Maybe something like
>
> Add support for <firstterm>large pages</firstterm> on Windows (Takayuki Tsunakawa, Thomas Munro)
> This is controlled by the <link>huge_pages</link> configuration parameter.
OK, done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 00:56 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 181+ messages in thread
From: Michael Paquier @ 2018-05-17 00:56 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Magnus Hagander <magnus@hagander.net>; Stephen Frost <sfrost@snowman.net>
On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> SCRAM-with-binding is the first password method that attempts to avoid
> man-in-the-middle attacks, and therefore is much less likely to be able
> to trust what the endpoints supports. I think it is really the
> channel_binding_mode that we want to control at the client. The lesser
> modes are much more reasonable to use an automatic best-supported
> negotiation, which is what we do now.
Noted. Which means that the parameter is ignored when using a non-SSL
connection, as well as when the server tries to enforce the use of
anything else than SCRAM.
> FYI, I think the server could also require channel binding for SCRAM. We
> already have scram-sha-256 in pg_hba.conf, and I think
> scram-sha-256-plus would be reasonable.
Noted as well. There is of course the question of v10 libpq versions
which don't support channel binding, but if an admin is willing to set
up scram-sha-256-plus in pg_hba.conf then he can request his users to
update his drivers/libs as well.
What's the take of others? Magnus, Stephen or Heikki perhaps (you've
been the most involved with SCRAM early talks)?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 01:09 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 2 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 01:09 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Magnus Hagander <magnus@hagander.net>; Stephen Frost <sfrost@snowman.net>
On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> > SCRAM-with-binding is the first password method that attempts to avoid
> > man-in-the-middle attacks, and therefore is much less likely to be able
> > to trust what the endpoints supports. I think it is really the
> > channel_binding_mode that we want to control at the client. The lesser
> > modes are much more reasonable to use an automatic best-supported
> > negotiation, which is what we do now.
>
> Noted. Which means that the parameter is ignored when using a non-SSL
> connection, as well as when the server tries to enforce the use of
> anything else than SCRAM.
Uh, a man-in-the-middle could prevent SSL or ask for a different
password authentication method and then channel binding would not be
used. I think when you say you want channel binding, you have to fail
if you don't get it.
> > FYI, I think the server could also require channel binding for SCRAM. We
> > already have scram-sha-256 in pg_hba.conf, and I think
> > scram-sha-256-plus would be reasonable.
>
> Noted as well. There is of course the question of v10 libpq versions
> which don't support channel binding, but if an admin is willing to set
> up scram-sha-256-plus in pg_hba.conf then he can request his users to
> update his drivers/libs as well.
Yes, I don't see a way around it. Once you accept that someone in the
middle can change what you request undetected, then you can't do
fallback. Imagine a man-in-the-middle with TLS where the
man-in-the-middle allows the two end-points to negotiate the shared
secret, but the man-in-the-middle forces a weak cipher. This is what is
happening with Postgres when the man-in-the-middle forces a weaker
authentication method.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 02:27 Amit Kapila <amit.kapila16@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Amit Kapila @ 2018-05-17 02:27 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Thu, May 17, 2018 at 5:54 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> Oh, sorry, changed to:
>
> Allow single-evaluation queries, e.g. <literal>WHERE</literal>
> clause aggregate queries, and functions in the target list to be
> parallelized (Amit Kapila, Robert Haas)
>
LGTM. Thanks.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 12:48 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Michael Paquier @ 2018-05-17 12:48 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Magnus Hagander <magnus@hagander.net>; Stephen Frost <sfrost@snowman.net>
On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote:
> On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
>> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
>>> SCRAM-with-binding is the first password method that attempts to avoid
>>> man-in-the-middle attacks, and therefore is much less likely to be able
>>> to trust what the endpoints supports. I think it is really the
>>> channel_binding_mode that we want to control at the client. The lesser
>>> modes are much more reasonable to use an automatic best-supported
>>> negotiation, which is what we do now.
>>
>> Noted. Which means that the parameter is ignored when using a non-SSL
>> connection, as well as when the server tries to enforce the use of
>> anything else than SCRAM.
>
> Uh, a man-in-the-middle could prevent SSL or ask for a different
> password authentication method and then channel binding would not be
> used. I think when you say you want channel binding, you have to fail
> if you don't get it.
I am not exactly sure what is the result we are looking for here, so I
am adding for now an open item which refers to this part of the thread.
Please note that I am fine to spend cycles if needed to address any
issues and/or concerns. Let's the discussion continue for now.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 13:35 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Michael Paquier @ 2018-05-17 13:35 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi Bruce,
Here is some bonus feedback.
On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> I expect a torrent of feedback. ;-)
I have just noticed that this entry does not have the correct author
(guess who?):
<para>
Add libpq option to support channel binding when using <link
linkend="auth-password"><acronym>SCRAM</acronym></link>
authentication (Peter Eisentraut)
</para>
I think that there should be two different entries in the release notes
for channel binding:
1) The new connection parameter in libpq which allows to control the
channel binding name, as well as to decide if it should be disabled.
I would think that this is better placed within the section for client
interface changes.
2) Channel binding itself, which should be part of the authentication
section.
<para>
Have libpq's <link
linkend="libpq-pqhost"><function>PQhost()</function></link>
always return the actual connected host (Hari Babu)
</para>
Should this be added as well in the section "Client interfaces"?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 13:38 Magnus Hagander <magnus@hagander.net>
parent: Michael Paquier <michael@paquier.xyz>
1 sibling, 0 replies; 181+ messages in thread
From: Magnus Hagander @ 2018-05-17 13:38 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Bruce Momjian <bruce@momjian.us>; Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Stephen Frost <sfrost@snowman.net>
On Thu, May 17, 2018 at 2:56 AM, Michael Paquier <michael@paquier.xyz>
wrote:
> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> > SCRAM-with-binding is the first password method that attempts to avoid
> > man-in-the-middle attacks, and therefore is much less likely to be able
> > to trust what the endpoints supports. I think it is really the
> > channel_binding_mode that we want to control at the client. The lesser
> > modes are much more reasonable to use an automatic best-supported
> > negotiation, which is what we do now.
>
> Noted. Which means that the parameter is ignored when using a non-SSL
> connection, as well as when the server tries to enforce the use of
> anything else than SCRAM.
>
(apologies if this was covered earlier, as I'm entering late into the
discussion)
"ignored" in combination with a security parameter is generally a very very
red flag.
If the client requests channel binding and ends up using a non encrypted
connection, surely the correct thing to do is fail the connection, rather
than downgrade the authentication?
We should really make sure we don't re-implement something as silly as our
current "sslmode=prefer", because it makes no sense. From the client side
perspective, there really only needs to be two choices -- "enforce channel
binding at level <x>" or "meh, I don't care". In the "meh, I don't care"
mode, go with whatever the server picks (through enforcement in pg_hba.conf
for example).
> FYI, I think the server could also require channel binding for SCRAM. We
> > already have scram-sha-256 in pg_hba.conf, and I think
> > scram-sha-256-plus would be reasonable.
>
> Noted as well. There is of course the question of v10 libpq versions
> which don't support channel binding, but if an admin is willing to set
> up scram-sha-256-plus in pg_hba.conf then he can request his users to
> update his drivers/libs as well.
>
Yes. And they *should* fail if they don't upgrade. That's what requirement
means... :)
What's the take of others? Magnus, Stephen or Heikki perhaps (you've
> been the most involved with SCRAM early talks)?
>
Saw it by luck. It would probably be better if it wasn't hidden deep in a
thread about release notes.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 13:55 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 13:55 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Magnus Hagander <magnus@hagander.net>; Stephen Frost <sfrost@snowman.net>
On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote:
> > > FYI, I think the server could also require channel binding for SCRAM. We
> > > already have scram-sha-256 in pg_hba.conf, and I think
> > > scram-sha-256-plus would be reasonable.
> >
> > Noted as well. There is of course the question of v10 libpq versions
> > which don't support channel binding, but if an admin is willing to set
> > up scram-sha-256-plus in pg_hba.conf then he can request his users to
> > update his drivers/libs as well.
>
> Yes, I don't see a way around it. Once you accept that someone in the
> middle can change what you request undetected, then you can't do
> fallback. Imagine a man-in-the-middle with TLS where the
> man-in-the-middle allows the two end-points to negotiate the shared
> secret, but the man-in-the-middle forces a weak cipher. This is what is
> happening with Postgres when the man-in-the-middle forces a weaker
> authentication method.
Technically, you can do automatic fallback if the fallback has
man-in-the-middle and downgrade protection. Technically, because TLS is
already active when we start authentication negotiation, we don't need
downgrade protection as long as we have man-in-the-middle protection.
Unfortunately, only SCRAM with channel binding and sslmode=verify-full
have man-in-the-middle protection. Therefore, downgrading from SCRAM
with channel binding to SCRAM without channel binding, MD5, or
'password' is only safe if sslmode=verify-full is enabled. Technically
MD5, or 'password' has weak or non-existent replay protection, but if we
are requiring TLS, then that doesn't really matter, assuming we have
man-in-the-middle protection.
I don't know if falling back from SCRAM with channel binding to a lesser
authentication methods only if sslmode=verify-full is enabled is really
helpful to anyone since it requires certificate installation.
TLS has similar downgrade issues:
http://www.educatedguesswork.org/2012/07/problems_with_secure_upgrade_t.html
but many of its downgrade options have downgrade protection, and you
don't lose man-in-the-middle protection by downgrading.
Man-in-the-middle protection via certificate checking happens
independent of the TLS version being used, which is not the case for
Postgres authentication downgrade options.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 13:56 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 13:56 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Heikki Linnakangas <hlinnaka@iki.fi>; PostgreSQL-development <pgsql-hackers@postgresql.org>; Magnus Hagander <magnus@hagander.net>; Stephen Frost <sfrost@snowman.net>
On Thu, May 17, 2018 at 09:48:54PM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote:
> > On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
> >> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> >>> SCRAM-with-binding is the first password method that attempts to avoid
> >>> man-in-the-middle attacks, and therefore is much less likely to be able
> >>> to trust what the endpoints supports. I think it is really the
> >>> channel_binding_mode that we want to control at the client. The lesser
> >>> modes are much more reasonable to use an automatic best-supported
> >>> negotiation, which is what we do now.
> >>
> >> Noted. Which means that the parameter is ignored when using a non-SSL
> >> connection, as well as when the server tries to enforce the use of
> >> anything else than SCRAM.
> >
> > Uh, a man-in-the-middle could prevent SSL or ask for a different
> > password authentication method and then channel binding would not be
> > used. I think when you say you want channel binding, you have to fail
> > if you don't get it.
>
> I am not exactly sure what is the result we are looking for here, so I
> am adding for now an open item which refers to this part of the thread.
> Please note that I am fine to spend cycles if needed to address any
> issues and/or concerns. Let's the discussion continue for now.
Agreed, and I just posted a more detailed email about when
authentication downgrades are possible.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-17 18:23 Bruce Momjian <bruce@momjian.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-17 18:23 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Thu, May 17, 2018 at 10:35:53PM +0900, Michael Paquier wrote:
> Hi Bruce,
>
> Here is some bonus feedback.
>
> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > I expect a torrent of feedback. ;-)
>
> I have just noticed that this entry does not have the correct author
> (guess who?):
Fixed. (I think I guessed right.)
> <para>
> Add libpq option to support channel binding when using <link
> linkend="auth-password"><acronym>SCRAM</acronym></link>
> authentication (Peter Eisentraut)
> </para>
>
> I think that there should be two different entries in the release notes
> for channel binding:
> 1) The new connection parameter in libpq which allows to control the
> channel binding name, as well as to decide if it should be disabled.
> I would think that this is better placed within the section for client
> interface changes.
Well, I tend to put items in the first section that applies, and in this
case, you are right that the API is libpq but the feature is
authentication. We know we are going to need to adjust this feature,
so let's see where it ends up and let's revisit it.
> 2) Channel binding itself, which should be part of the authentication
> section.
>
> <para>
> Have libpq's <link
> linkend="libpq-pqhost"><function>PQhost()</function></link>
> always return the actual connected host (Hari Babu)
> </para>
> Should this be added as well in the section "Client interfaces"?
Well, again, using the rules above, the PQhost item goes into the first
section where it fits, and incompatibility is the first such section.
There are other items in incompatibility that could be moved to lower,
but again, we want the incompatibilities to all be in the same place.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-18 01:19 Michael Paquier <michael@paquier.xyz>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Michael Paquier @ 2018-05-18 01:19 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Thu, May 17, 2018 at 02:23:00PM -0400, Bruce Momjian wrote:
> On Thu, May 17, 2018 at 10:35:53PM +0900, Michael Paquier wrote:
> > Hi Bruce,
> >
> > Here is some bonus feedback.
> >
> > On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > > I expect a torrent of feedback. ;-)
> >
> > I have just noticed that this entry does not have the correct author
> > (guess who?):
>
> Fixed. (I think I guessed right.)
Thanks, Bruce. It looks that your guess is right.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-18 05:56 Andrey Borodin <x4mmm@yandex-team.ru>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Andrey Borodin @ 2018-05-18 05:56 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
H, Bruce!
> 11 мая 2018 г., в 20:08, Bruce Momjian <bruce@momjian.us> написал(а):
>
> I expect a torrent of feedback. ;-)
I'm not sure it is usefull in release notes since it is more about API, and not user-facing change. Just in case.
GiST opclasses now can omit compress and decompress functions. If compress function is omited, IndexOnlyScan is enabled for opclass without any extra change.
https://github.com/postgres/postgres/commit/d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128 <https://github.com/postgres/postgres/commit/d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128;
Best regards, Andrey Borodin.=
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-18 10:28 Amit Kapila <amit.kapila16@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Amit Kapila @ 2018-05-18 10:28 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Dilip Kumar <dilipbalaut@gmail.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 15, 2018 at 2:11 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, May 14, 2018 at 05:34:54PM +0530, Dilip Kumar wrote:
>>
>> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> I have committed the first draft of the Postgres 11 release notes. I
>> will add more markup soon. You can view the most current version here:
>>
>> http://momjian.us/pgsql_docs/release-11.html
>>
>> I expect a torrent of feedback. ;-)
>>
>> On a personal note, I want to apologize for not adequately championing
>> two features that I think have strategic significance but didn't make it
>> into Postgres 11: parallel FDW access and improved multi-variate
>> statistics. I hope to do better job during Postgres 12.
>>
>> --
>> Bruce Momjian <bruce@momjian.us> http://momjian.us
>> EnterpriseDB http://enterprisedb.com
>>
>> + As you are, so once was I. As I am, so you will be. +
>> + Ancient Roman grave inscription +
>>
>>
>>
>> I think the below commit is missed in the release notes?
>>
>> 5edc63bda68a77c4d38f0cbeae1c4271f9ef4100
>>
>> Committer: Robert Haas <rhaas@postgresql.org> 2017-11-10 13:50:50
>>
>> Account for the effect of lossy pages when costing bitmap scans.
>>
>> Dilip Kumar, reviewed by Alexander Kumenkov, Amul Sul, and me.
>> Some final adjustments by me.
>>
>> As part of this commit, we are also accounting for the lossy pages during
>> bitmap costing. This will consider
>> the effect of work_mem while selecting the bitmap heap scan path.
>
> Uh, that seems very exotic to mention, sorry. Others have opinions?
>
This patch improves the plan selection in many cases, see the
discussion of this patch[1][2]. The change in plan leads to
significant performance improvements in a number of TPC-H queries at
various settings. I think it is worth considering to add this in the
release notes.
[1] - https://www.postgresql.org/message-id/CAFiTN-uL%3DrQtvt9zFnLV9khXODhEyJTvC4TB135HSK1%3DYdFAxQ%40mail...
[2] - https://www.postgresql.org/message-id/9daaf288-e67f-f349-965f-3a8c6e0819ae%40postgrespro.ru
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-18 13:53 Bruce Momjian <bruce@momjian.us>
parent: Andrey Borodin <x4mmm@yandex-team.ru>
0 siblings, 2 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-18 13:53 UTC (permalink / raw)
To: Andrey Borodin <x4mmm@yandex-team.ru>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 18, 2018 at 10:56:25AM +0500, Andrey Borodin wrote:
> H, Bruce!
>
>
> 11 мая 2018 г., в 20:08, Bruce Momjian <bruce@momjian.us> написал(а):
>
> I expect a torrent of feedback. ;-)
>
>
> I'm not sure it is usefull in release notes since it is more about API, and not
> user-facing change. Just in case.
> GiST opclasses now can omit compress and decompress functions. If compress
> function is omited, IndexOnlyScan is enabled for opclass without any extra
> change.
> https://github.com/postgres/postgres/commit/
> d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
Uh, we do have this for SP-GiST:
Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
I am unclear how far downt the API stack I should go in documenting
changes like this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-18 14:28 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 2 replies; 181+ messages in thread
From: Tom Lane @ 2018-05-18 14:28 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
While we're all griping about omissions from the release notes ...
I think you should have documented that we fixed plpgsql to cope
(or cope better, at least) with intrasession changes in the rowtypes
of composite-type variables. See bug #15203 for the latest in a long
line of user complaints about that --- so it's not like this is
something users don't care about.
regards, tom lane
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-18 15:56 Jonathan S. Katz <jkatz@postgresql.org>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Jonathan S. Katz @ 2018-05-18 15:56 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
> On May 11, 2018, at 11:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback. ;-)
Per feedback from many asynchronous threads, attached is the proposed
patch for the list of major features. I also expect a torrent of feedback. I
will have a corresponding press release for Beta 1 in the very near future.
This being my first doc patch proposal, I tried to follow the formatting I
saw in the existing SGML. Please let me know if I can make improvements.
Thanks,
Jonathan
Attachments:
pg11features.diff (application/octet-stream, 3.1K) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 9dd8dff081..6adc312871 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -20,7 +20,104 @@
<itemizedlist>
- <listitem><para>XXX</para></listitem>
+ <listitem>
+ <para>Major improvements to partitioning
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Partitioning by a hash key
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>UPDATE</command> statements issued to a partition key
+ now move affected rows to the appropriate partitions
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Improved <command>SELECT</command> query performance due to
+ enhanced partition elimination during query processing and
+ execution
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Support for <literal>PRIMARY KEY</literal>, <literal>FOREIGN
+ KEY</literal>, indexes, and triggers
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Improvements to parallelism
+ <itemizedlist>
+
+ <listitem>
+ <para>Parallelized hash joins</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Parallelized <command>CREATE INDEX</command> for B-tree indexes
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Parallelized <command>CREATE TABLE .. AS</command>,
+ <command>CREATE MATERIALIZED VIEW</command>, and certain
+ queries with <literal>UNION</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ SQL stored procedures with support for embedded transactions
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ JIT compilation introduced, including support for fast evaluation of
+ expressions
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Window functions now support all options shown in the SQL:2011
+ standard, including <literal>RANGE <distance> PRECEDING/FOLLOWING
+ </literal>, <literal>GROUPS</literal> mode, and frame exclusion
+ options.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Channel binding for SCRAM authentication to prevent potential
+ man-in-the-middle attacks
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Many other useful performance improvements, including fast
+ <command>ALTER TABLE .. ADD COLUMN</command> with a
+ non-<literal>NULL</literal> default
+ </para>
+ </listitem>
</itemizedlist>
<para>
* Re: Postgres 11 release notes
@ 2018-05-18 15:58 Amit Langote <amitlangote09@gmail.com>
parent: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
0 siblings, 2 replies; 181+ messages in thread
From: Amit Langote @ 2018-05-18 15:58 UTC (permalink / raw)
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi Bruce.
On Tue, May 15, 2018 at 12:46 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/05/15 5:30, Bruce Momjian wrote:
>> I like it, done.
>
> Thank you.
I wonder what you think about including this little performance item:
https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
especially considering the part of the commit message which states
...Still, testing shows
that this makes single-row inserts significantly faster on a table
with many partitions without harming the bulk-insert case.
I recall seeing those inserts being as much as 2x faster as partition
count grows beyond hundreds. One might argue that we should think
about publicizing this only after we've dealt with the
lock-all-partitions issue that's also mentioned in the commit message
which is still a significant portion of the time spent and I'm totally
fine with that.
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-21 07:34 David Rowley <david.rowley@2ndquadrant.com>
parent: Amit Langote <amitlangote09@gmail.com>
1 sibling, 3 replies; 181+ messages in thread
From: David Rowley @ 2018-05-21 07:34 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 19 May 2018 at 03:58, Amit Langote <amitlangote09@gmail.com> wrote:
> I wonder what you think about including this little performance item:
>
> https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
>
> especially considering the part of the commit message which states
>
> ...Still, testing shows
> that this makes single-row inserts significantly faster on a table
> with many partitions without harming the bulk-insert case.
>
> I recall seeing those inserts being as much as 2x faster as partition
> count grows beyond hundreds. One might argue that we should think
> about publicizing this only after we've dealt with the
> lock-all-partitions issue that's also mentioned in the commit message
> which is still a significant portion of the time spent and I'm totally
> fine with that.
While I do think that was a good change, I do think there's much still
left to do to speed up usage of partitioned tables with many
partitions.
I've been working a bit in this area over the past few weeks and with
PG11 I measured a single INSERT into a 10k RANGE partitioned table at
just 84 tps (!), while inserting the same row into a non-partitioned
table was about 11.1k tps. I have patches locally that take this up to
~9.8k tps, which I'll submit for PG12. I'm unsure if we should be
shouting anything from the rooftops about the work done in this area
for PG11, since it's still got a long way to go still before the
feature is usable with higher numbers of partitions. I do think your
change was a good one to make, but I just don't want users to think
that we're done here when we all know that much work remains.
If we're going to add an item in the release notes about this then I
wouldn't object, providing it could be done in a way that indicates
we've not finished here yet, but if that's the case then maybe it's
better to say nothing at all.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-21 08:28 Haribabu Kommi <kommi.haribabu@gmail.com>
parent: David Rowley <david.rowley@2ndquadrant.com>
2 siblings, 1 reply; 181+ messages in thread
From: Haribabu Kommi @ 2018-05-21 08:28 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, May 12, 2018 at 1:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
Thanks for preparing the release notes.
>Have pg_dump dump all aspects of a database (Haribabu Kommi)
>
>pg_dump and pg_restore, without --clean, no longer dump/restore database
> comments and security labels.
There is small change in option name, the option to print database comments
is --create not --clean.
>Have libpq's PQhost() always return the actual connected host (Hari Babu)
>
>Previously PQhost() often returned the supplied host parameters, which
could contain
>several hosts. The same is true of PQport(), which now returns the actual
port number,
>not the multiple supplied port numbers. ACCURATE?
Now PQhost() can return hostaddr also if host is not available. How about
changing as below?
Have libpq's PQhost() always return the actual connected host/hostaddr
(Haribabu Kommi)
hostaddr is returned, when there is no host available with the connected
host.
Regards,
Haribabu Kommi
Fujitsu Australia
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-21 14:58 Amit Langote <amitlangote09@gmail.com>
parent: David Rowley <david.rowley@2ndquadrant.com>
2 siblings, 0 replies; 181+ messages in thread
From: Amit Langote @ 2018-05-21 14:58 UTC (permalink / raw)
To: David Rowley <david.rowley@2ndquadrant.com>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 21, 2018 at 4:34 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 19 May 2018 at 03:58, Amit Langote <amitlangote09@gmail.com> wrote:
>> I wonder what you think about including this little performance item:
>>
>> https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
>>
>> especially considering the part of the commit message which states
>>
>> ...Still, testing shows
>> that this makes single-row inserts significantly faster on a table
>> with many partitions without harming the bulk-insert case.
>>
>> I recall seeing those inserts being as much as 2x faster as partition
>> count grows beyond hundreds. One might argue that we should think
>> about publicizing this only after we've dealt with the
>> lock-all-partitions issue that's also mentioned in the commit message
>> which is still a significant portion of the time spent and I'm totally
>> fine with that.
>
> While I do think that was a good change, I do think there's much still
> left to do to speed up usage of partitioned tables with many
> partitions.
>
> I've been working a bit in this area over the past few weeks and with
> PG11 I measured a single INSERT into a 10k RANGE partitioned table at
> just 84 tps (!), while inserting the same row into a non-partitioned
> table was about 11.1k tps. I have patches locally that take this up to
> ~9.8k tps, which I'll submit for PG12. I'm unsure if we should be
> shouting anything from the rooftops about the work done in this area
> for PG11, since it's still got a long way to go still before the
> feature is usable with higher numbers of partitions. I do think your
> change was a good one to make, but I just don't want users to think
> that we're done here when we all know that much work remains.
>
> If we're going to add an item in the release notes about this then I
> wouldn't object, providing it could be done in a way that indicates
> we've not finished here yet, but if that's the case then maybe it's
> better to say nothing at all.
You're right, it surely isn't time yet to make fanfare about this. I
will look forward to being able to review your patches. :-)
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-21 16:38 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 1 reply; 181+ messages in thread
From: Tom Lane @ 2018-05-21 16:38 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> Per feedback from many asynchronous threads, attached is the proposed
> patch for the list of major features. I also expect a torrent of feedback. I
> will have a corresponding press release for Beta 1 in the very near future.
> This being my first doc patch proposal, I tried to follow the formatting I
> saw in the existing SGML. Please let me know if I can make improvements.
Pushed with some very minor editorialization.
regards, tom lane
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-21 16:52 Jonathan S. Katz <jkatz@postgresql.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 181+ messages in thread
From: Jonathan S. Katz @ 2018-05-21 16:52 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
> On May 21, 2018, at 12:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> Per feedback from many asynchronous threads, attached is the proposed
>> patch for the list of major features. I also expect a torrent of feedback. I
>> will have a corresponding press release for Beta 1 in the very near future.
>> This being my first doc patch proposal, I tried to follow the formatting I
>> saw in the existing SGML. Please let me know if I can make improvements.
>
> Pushed with some very minor editorialization.
Thanks! I do agree with your editorial, the main goal now is to give exposure to features for testing.
Jonathan
^ permalink raw reply [nested|flat] 181+ messages in thread
* RE: Postgres 11 release notes
@ 2018-05-22 02:36 Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 0 replies; 181+ messages in thread
From: Ideriha, Takeshi @ 2018-05-22 02:36 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
>-----Original Message-----
>From: Bruce Momjian [mailto:bruce@momjian.us]
>I have committed the first draft of the Postgres 11 release notes. I will add more
>markup soon. You can view the most current version here:
Hi, there is a small typo.
I think "These function" should be "These functions".
(At the next sentece "these functions" is used.)
Regards,
Ideriha, Takeshi
Attachments:
release_note_typo.patch (application/octet-stream, 575B) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index dedeb9d..0e4a0f8 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -374,7 +374,7 @@
</para>
<para>
- These function are now present by default. Old <link
+ These functions are now present by default. Old <link
linkend="adminpack"><application>adminpack</application></link>
installs will continue to have access to these functions until
they are updated via <command>ALTER EXTENSION ... UPDATE</command>.
* Re: Postgres 11 release notes
@ 2018-05-23 01:02 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 01:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 18, 2018 at 10:28:12AM -0400, Tom Lane wrote:
> While we're all griping about omissions from the release notes ...
> I think you should have documented that we fixed plpgsql to cope
> (or cope better, at least) with intrasession changes in the rowtypes
> of composite-type variables. See bug #15203 for the latest in a long
> line of user complaints about that --- so it's not like this is
> something users don't care about.
It was fixed in this commit, right?
commit 4b93f57999a2ca9b9c9e573ea32ab1aeaa8bf496
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue Feb 13 18:52:21 2018 -0500
Make plpgsql use its DTYPE_REC code paths for composite-type variables.
Sure I can add it, once you confirm.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:16 Bruce Momjian <bruce@momjian.us>
parent: Amit Langote <amitlangote09@gmail.com>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 01:16 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, May 19, 2018 at 12:58:04AM +0900, Amit Langote wrote:
> Hi Bruce.
>
> On Tue, May 15, 2018 at 12:46 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> > On 2018/05/15 5:30, Bruce Momjian wrote:
> >> I like it, done.
> >
> > Thank you.
>
> I wonder what you think about including this little performance item:
>
> https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
>
> especially considering the part of the commit message which states
>
> ...Still, testing shows
> that this makes single-row inserts significantly faster on a table
> with many partitions without harming the bulk-insert case.
>
> I recall seeing those inserts being as much as 2x faster as partition
> count grows beyond hundreds. One might argue that we should think
> about publicizing this only after we've dealt with the
> lock-all-partitions issue that's also mentioned in the commit message
> which is still a significant portion of the time spent and I'm totally
> fine with that.
Uh, we already have this in the release notes:
Allow faster partition elimination during query processing (Amit
Langote, David Rowley, Dilip Kumar)
This speeds access to partitioned tables with many partitions.
Do you want me to add the git commit hash to this release note entry?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:18 Bruce Momjian <bruce@momjian.us>
parent: David Rowley <david.rowley@2ndquadrant.com>
2 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 01:18 UTC (permalink / raw)
To: David Rowley <david.rowley@2ndquadrant.com>; +Cc: Amit Langote <amitlangote09@gmail.com>; Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 21, 2018 at 07:34:18PM +1200, David Rowley wrote:
> On 19 May 2018 at 03:58, Amit Langote <amitlangote09@gmail.com> wrote:
> > I wonder what you think about including this little performance item:
> >
> > https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
> >
> > especially considering the part of the commit message which states
> >
> > ...Still, testing shows
> > that this makes single-row inserts significantly faster on a table
> > with many partitions without harming the bulk-insert case.
> >
> > I recall seeing those inserts being as much as 2x faster as partition
> > count grows beyond hundreds. One might argue that we should think
> > about publicizing this only after we've dealt with the
> > lock-all-partitions issue that's also mentioned in the commit message
> > which is still a significant portion of the time spent and I'm totally
> > fine with that.
>
> While I do think that was a good change, I do think there's much still
> left to do to speed up usage of partitioned tables with many
> partitions.
>
> I've been working a bit in this area over the past few weeks and with
> PG11 I measured a single INSERT into a 10k RANGE partitioned table at
> just 84 tps (!), while inserting the same row into a non-partitioned
> table was about 11.1k tps. I have patches locally that take this up to
> ~9.8k tps, which I'll submit for PG12. I'm unsure if we should be
Yikes! I think the question is whether we need to _remove_ the item I
just posted that is already in the release notes:
Allow faster partition elimination during query processing (Amit
Langote, David Rowley, Dilip Kumar)
This speeds access to partitioned tables with many partitions.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: [Sender Address Forgery]Re: Postgres 11 release notes
@ 2018-05-23 01:28 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Langote @ 2018-05-23 01:28 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; Amit Langote <amitlangote09@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018/05/23 10:16, Bruce Momjian wrote:
> On Sat, May 19, 2018 at 12:58:04AM +0900, Amit Langote wrote:
>> Hi Bruce.
>>
>> On Tue, May 15, 2018 at 12:46 PM, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> On 2018/05/15 5:30, Bruce Momjian wrote:
>>>> I like it, done.
>>>
>>> Thank you.
>>
>> I wonder what you think about including this little performance item:
>>
>> https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
>>
>> especially considering the part of the commit message which states
>>
>> ...Still, testing shows
>> that this makes single-row inserts significantly faster on a table
>> with many partitions without harming the bulk-insert case.
>>
>> I recall seeing those inserts being as much as 2x faster as partition
>> count grows beyond hundreds. One might argue that we should think
>> about publicizing this only after we've dealt with the
>> lock-all-partitions issue that's also mentioned in the commit message
>> which is still a significant portion of the time spent and I'm totally
>> fine with that.
>
> Uh, we already have this in the release notes:
>
> Allow faster partition elimination during query processing (Amit
> Langote, David Rowley, Dilip Kumar)
>
> This speeds access to partitioned tables with many partitions.
>
> Do you want me to add the git commit hash to this release note entry?
I suppose you meant the above as an entry for performance improvement of
partition "pruning". The commit I quoted is concerned with making "tuple
routing" a bit faster, but as David said that's not making it as fast as
it could really be. So, we should hold off from touting it as an
improvement at this point and I have to agree. Sorry for the noise.
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:34 Bruce Momjian <bruce@momjian.us>
parent: Haribabu Kommi <kommi.haribabu@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 01:34 UTC (permalink / raw)
To: Haribabu Kommi <kommi.haribabu@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Mon, May 21, 2018 at 06:28:36PM +1000, Haribabu Kommi wrote:
> On Sat, May 12, 2018 at 1:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
>
> Thanks for preparing the release notes.
>
> >Have pg_dump dump all aspects of a database (Haribabu Kommi)
> >
> >pg_dump and pg_restore, without --clean, no longer dump/restore database
> > comments and security labels.
>
> There is small change in option name, the option to print database comments is
> --create not --clean.
Uh, what about security labels?
> >Have libpq's PQhost() always return the actual connected host (Hari Babu)
> >
> >Previously PQhost() often returned the supplied host parameters, which could
> contain
> >several hosts. The same is true of PQport(), which now returns the actual port
> number,
> >not the multiple supplied port numbers. ACCURATE?
>
> Now PQhost() can return hostaddr also if host is not available. How about
> changing as below?
>
> Have libpq's PQhost() always return the actual connected host/hostaddr
> (Haribabu Kommi)
>
> hostaddr is returned, when there is no host available with the connected host.
OK, here is the new text:
Have libpq's <link
linkend="libpq-pqhost"><function>PQhost()</function></link>
always return the actual connected host (Hari Babu)
Previously <function>PQhost()</function> often returned the
supplied host parameters, which could contain several hosts.
-> It will now also return the host's IP address if the host name was
-> not supplied. The same is true of <function>PQport()</function>,
which now returns the actual port number, not the multiple supplied
port numbers.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: [Sender Address Forgery]Re: Postgres 11 release notes
@ 2018-05-23 01:36 Bruce Momjian <bruce@momjian.us>
parent: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 01:36 UTC (permalink / raw)
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; +Cc: Amit Langote <amitlangote09@gmail.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 23, 2018 at 10:28:41AM +0900, Amit Langote wrote:
> > Uh, we already have this in the release notes:
> >
> > Allow faster partition elimination during query processing (Amit
> > Langote, David Rowley, Dilip Kumar)
> >
> > This speeds access to partitioned tables with many partitions.
> >
> > Do you want me to add the git commit hash to this release note entry?
>
> I suppose you meant the above as an entry for performance improvement of
> partition "pruning". The commit I quoted is concerned with making "tuple
> routing" a bit faster, but as David said that's not making it as fast as
> it could really be. So, we should hold off from touting it as an
> improvement at this point and I have to agree. Sorry for the noise.
OK, no problem. So _finding_ the rows is faster, but adding rows to
partitioned tables with many partitions is still slow, got it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:37 Thomas Munro <thomas.munro@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 181+ messages in thread
From: Thomas Munro @ 2018-05-23 01:37 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, May 19, 2018 at 2:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> While we're all griping about omissions from the release notes ...
Hi Bruce,
<para>
Add support for <productname>ARMv8</productname> hardware
<acronym>CRC</acronym> calculations (Yuqi Gu, Heikki Linnakangas)
</para>
Could I please ask for a third author credit for this one? See
commits 1c72ec6 (and follow-up a7a7387) which extended ARM CRC support
to non-Linux systems.
--
Thomas Munro
http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:42 Bruce Momjian <bruce@momjian.us>
parent: Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 01:42 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@enterprisedb.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 23, 2018 at 01:37:22PM +1200, Thomas Munro wrote:
> On Sat, May 19, 2018 at 2:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > While we're all griping about omissions from the release notes ...
>
> Hi Bruce,
>
> <para>
> Add support for <productname>ARMv8</productname> hardware
> <acronym>CRC</acronym> calculations (Yuqi Gu, Heikki Linnakangas)
> </para>
>
> Could I please ask for a third author credit for this one? See
> commits 1c72ec6 (and follow-up a7a7387) which extended ARM CRC support
> to non-Linux systems.
Done.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:54 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Amit Langote @ 2018-05-23 01:54 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Amit Langote <amitlangote09@gmail.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018/05/23 10:36, Bruce Momjian wrote:
> On Wed, May 23, 2018 at 10:28:41AM +0900, Amit Langote wrote:
>>> Uh, we already have this in the release notes:
>>>
>>> Allow faster partition elimination during query processing (Amit
>>> Langote, David Rowley, Dilip Kumar)
>>>
>>> This speeds access to partitioned tables with many partitions.
>>>
>>> Do you want me to add the git commit hash to this release note entry?
>>
>> I suppose you meant the above as an entry for performance improvement of
>> partition "pruning". The commit I quoted is concerned with making "tuple
>> routing" a bit faster, but as David said that's not making it as fast as
>> it could really be. So, we should hold off from touting it as an
>> improvement at this point and I have to agree. Sorry for the noise.
>
> OK, no problem. So _finding_ the rows is faster, but adding rows to
> partitioned tables with many partitions is still slow, got it.
Yeah.
To be honest, even _finding_ is not yet performing the best it could be,
which I guess David would chime in to say. We know what needs to be fixed
to get the close-to-ideal performance there, but didn't have time to do it
for PG 11. To clarify, what changed is that we replaced constraint
exclusion, which has to consider the partition constraint of *all*
partitions individually, as an algorithm for partition pruning by a faster
alternative that only looks at the parent table's partition descriptor.
That gives a good boost but that's not the end of it. Moreover, addition
of this new pruning algorithm enabled the development of execution time
pruning which is a completely new feature.
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 01:55 Haribabu Kommi <kommi.haribabu@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Haribabu Kommi @ 2018-05-23 01:55 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 23, 2018 at 11:34 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, May 21, 2018 at 06:28:36PM +1000, Haribabu Kommi wrote:
> > On Sat, May 12, 2018 at 1:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version
> here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> >
> > Thanks for preparing the release notes.
> >
> > >Have pg_dump dump all aspects of a database (Haribabu Kommi)
> > >
> > >pg_dump and pg_restore, without --clean, no longer dump/restore database
> > > comments and security labels.
> >
> > There is small change in option name, the option to print database
> comments is
> > --create not --clean.
>
> Uh, what about security labels?
>
Yes, security labels also gets dumped only with --create option.
> > >Have libpq's PQhost() always return the actual connected host (Hari
> Babu)
> > >
> > >Previously PQhost() often returned the supplied host parameters, which
> could
> > contain
> > >several hosts. The same is true of PQport(), which now returns the
> actual port
> > number,
> > >not the multiple supplied port numbers. ACCURATE?
> >
> > Now PQhost() can return hostaddr also if host is not available. How about
> > changing as below?
> >
> > Have libpq's PQhost() always return the actual connected host/hostaddr
> > (Haribabu Kommi)
> >
> > hostaddr is returned, when there is no host available with the connected
> host.
>
> OK, here is the new text:
>
> Have libpq's <link
> linkend="libpq-pqhost"><function>PQhost()</function></link>
> always return the actual connected host (Hari Babu)
>
Can you update the author name as (Haribabu Kommi) to make it consistent
with other entries.
> Previously <function>PQhost()</function> often returned the
> supplied host parameters, which could contain several hosts.
> -> It will now also return the host's IP address if the host name was
> -> not supplied. The same is true of <function>PQport()</function>,
> which now returns the actual port number, not the multiple supplied
> port numbers.
That looks good to me.
Regards,
Haribabu Kommi
Fujitsu Australia
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 02:06 David Rowley <david.rowley@2ndquadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: David Rowley @ 2018-05-23 02:06 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Amit Langote <amitlangote09@gmail.com>; Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 23 May 2018 at 13:18, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, May 21, 2018 at 07:34:18PM +1200, David Rowley wrote:
>> I've been working a bit in this area over the past few weeks and with
>> PG11 I measured a single INSERT into a 10k RANGE partitioned table at
>> just 84 tps (!), while inserting the same row into a non-partitioned
>> table was about 11.1k tps. I have patches locally that take this up to
>> ~9.8k tps, which I'll submit for PG12. I'm unsure if we should be
>
> Yikes! I think the question is whether we need to _remove_ the item I
> just posted that is already in the release notes:
>
> Allow faster partition elimination during query processing (Amit
> Langote, David Rowley, Dilip Kumar)
>
> This speeds access to partitioned tables with many partitions.
Well, partition elimination/pruning and tuple routing are not the same
thing. Pruning saves us scanning partitions that can't contain
matching tuples, whereas routing finds a home for a specific tuple.
Amit's work to improve partition elimination certainly is much faster
than constraint exclusion. It's not the last thing we'll ever do to
speed up the planning of queries for partitioned tables but it is a
very good start, and without it, run-time pruning would not be
possible.
I'd say the release notes in this regard don't claim anything that's
untrue. They look fine to me. Thanks for working on them!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 02:40 Bruce Momjian <bruce@momjian.us>
parent: Haribabu Kommi <kommi.haribabu@gmail.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 02:40 UTC (permalink / raw)
To: Haribabu Kommi <kommi.haribabu@gmail.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 23, 2018 at 11:55:29AM +1000, Haribabu Kommi wrote:
> Yes, security labels also gets dumped only with --create option.
OK.
> Can you update the author name as (Haribabu Kommi) to make it consistent
> with other entries.
Done. Applied patch attached.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachments:
diff (text/x-diff, 1.2K) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
new file mode 100644
index c02bf0e..05fd23f
*** a/doc/src/sgml/release-11.sgml
--- b/doc/src/sgml/release-11.sgml
***************
*** 169,175 ****
<para>
<application>pg_dump</application> and
<application>pg_restore</application>, without
! <option>--clean</option>, no longer dump/restore database comments
and security labels.
</para>
--- 169,175 ----
<para>
<application>pg_dump</application> and
<application>pg_restore</application>, without
! <option>--create</option>, no longer dump/restore database comments
and security labels.
</para>
***************
*** 287,293 ****
<para>
Have libpq's <link
linkend="libpq-pqhost"><function>PQhost()</function></link>
! always return the actual connected host (Hari Babu)
</para>
<para>
--- 287,293 ----
<para>
Have libpq's <link
linkend="libpq-pqhost"><function>PQhost()</function></link>
! always return the actual connected host (Haribabu Kommi)
</para>
<para>
* Re: Postgres 11 release notes
@ 2018-05-23 02:41 Bruce Momjian <bruce@momjian.us>
parent: David Rowley <david.rowley@2ndquadrant.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-23 02:41 UTC (permalink / raw)
To: David Rowley <david.rowley@2ndquadrant.com>; +Cc: Amit Langote <amitlangote09@gmail.com>; Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Wed, May 23, 2018 at 02:06:15PM +1200, David Rowley wrote:
> On 23 May 2018 at 13:18, Bruce Momjian <bruce@momjian.us> wrote:
> > On Mon, May 21, 2018 at 07:34:18PM +1200, David Rowley wrote:
> >> I've been working a bit in this area over the past few weeks and with
> >> PG11 I measured a single INSERT into a 10k RANGE partitioned table at
> >> just 84 tps (!), while inserting the same row into a non-partitioned
> >> table was about 11.1k tps. I have patches locally that take this up to
> >> ~9.8k tps, which I'll submit for PG12. I'm unsure if we should be
> >
> > Yikes! I think the question is whether we need to _remove_ the item I
> > just posted that is already in the release notes:
> >
> > Allow faster partition elimination during query processing (Amit
> > Langote, David Rowley, Dilip Kumar)
> >
> > This speeds access to partitioned tables with many partitions.
>
> Well, partition elimination/pruning and tuple routing are not the same
> thing. Pruning saves us scanning partitions that can't contain
> matching tuples, whereas routing finds a home for a specific tuple.
I just suspected they would use the same algorithm.
> Amit's work to improve partition elimination certainly is much faster
> than constraint exclusion. It's not the last thing we'll ever do to
> speed up the planning of queries for partitioned tables but it is a
> very good start, and without it, run-time pruning would not be
> possible.
>
> I'd say the release notes in this regard don't claim anything that's
> untrue. They look fine to me. Thanks for working on them!
OK.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-23 03:31 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Tom Lane @ 2018-05-23 03:31 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, May 18, 2018 at 10:28:12AM -0400, Tom Lane wrote:
>> While we're all griping about omissions from the release notes ...
>> I think you should have documented that we fixed plpgsql to cope
>> (or cope better, at least) with intrasession changes in the rowtypes
>> of composite-type variables.
> It was fixed in this commit, right?
> commit 4b93f57999a2ca9b9c9e573ea32ab1aeaa8bf496
That was the main one, anyway.
regards, tom lane
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-05-24 02:06 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-05-24 02:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Tue, May 22, 2018 at 11:31:08PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Fri, May 18, 2018 at 10:28:12AM -0400, Tom Lane wrote:
> >> While we're all griping about omissions from the release notes ...
> >> I think you should have documented that we fixed plpgsql to cope
> >> (or cope better, at least) with intrasession changes in the rowtypes
> >> of composite-type variables.
>
> > It was fixed in this commit, right?
> > commit 4b93f57999a2ca9b9c9e573ea32ab1aeaa8bf496
>
> That was the main one, anyway.
OK, added. Applied patch attached.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachments:
diff (text/plain, 821B) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
new file mode 100644
index 05fd23f..7599c6f
*** a/doc/src/sgml/release-11.sgml
--- b/doc/src/sgml/release-11.sgml
*************** same commits as above
*** 1982,1987 ****
--- 1982,2004 ----
<listitem>
<!--
+ 2018-02-13 [4b93f5799] Make plpgsql use its DTYPE_REC code paths for composite-
+
+ -->
+
+ <para>
+ Allow PL/pgSQL to handle changes to composite types (e.g. record,
+ row) that happen between the first and later function executions
+ in the same session (Tom Lane)
+ </para>
+
+ <para>
+ Previously such circumstances generated errors.
+ </para>
+ </listitem>
+
+ <listitem>
+ <!--
2018-03-28 [3f44e3db7] Transforms for jsonb to PL/Python
-->
* Re: Postgres 11 release notes
@ 2018-06-09 20:35 David G. Johnston <david.g.johnston@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 2 replies; 181+ messages in thread
From: David G. Johnston @ 2018-06-09 20:35 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, May 11, 2018 at 8:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
Some thoughts:
As a major item:
""""
JIT compilation of some SQL code, including support for fast evaluation of
expressions
""""
leaves me wondering what the general benefit is to the user. Also,
spelling out "Just-In-Time (JIT)" here seems warranted.
"""
No longer retain WAL that spans two checkpoints (Simon Riggs)
The retention of WAL records for only one checkpoint is required.
"""
Maybe: "Servers now only ensure that a single checkpoint record is present
in the locally retained WAL. Previously it would ensure at least two
checkpoints were available for recovery."
"""
Also, if any table mentioned in VACUUM uses a column list, then ANALYZE
keyword must be supplied; previously ANALYZE was implied in such cases.
"""
Should that be mentioned in the compatibility notes?
"""
Add the ability to define PL/pgSQL record types as not null, constant, or
with initial values (Tom Lane)
"""
Found the commit message for this one - should we back-patch a
documentation change indicating that this doesn't work prior to v11?
David J.
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-09 20:58 Jonathan S. Katz <jkatz@postgresql.org>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 181+ messages in thread
From: Jonathan S. Katz @ 2018-06-09 20:58 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
> On Jun 9, 2018, at 4:35 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Fri, May 11, 2018 at 8:08 AM, Bruce Momjian <bruce@momjian.us <mailto:bruce@momjian.us>> wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html <http://momjian.us/pgsql_docs/release-11.html;
>
> Some thoughts:
>
> As a major item:
> """"
> JIT compilation of some SQL code, including support for fast evaluation of expressions
> """"
>
> leaves me wondering what the general benefit is to the user. Also, spelling out "Just-In-Time (JIT)" here seems warranted.
+1 for spelling it out.
Looking through past release notes[1][2], we’ve typically left the context for
the features press releases[3].
Now, as the beta press release (feature-explanation oriented) typically differs from
the major version press release (use-case/context oriented), perhaps we could
incorporate some of the elements from the beta press release into the
“Major Features” section. It would be a departure from the release notes of recent
memory, but perhaps it would be more helpful.
Thoughts?
Jonathan
[1] https://www.postgresql.org/docs/11/static/release-10.html <https://www.postgresql.org/docs/11/static/release-10.html;
[2] https://www.postgresql.org/docs/11/static/release-9-6.html <https://www.postgresql.org/docs/11/static/release-9-6.html;
[3] https://www.postgresql.org/about/news/1855/ <https://www.postgresql.org/about/news/1855/>=
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-09 23:20 Justin Pryzby <pryzby@telsasoft.com>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 181+ messages in thread
From: Justin Pryzby @ 2018-06-09 23:20 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Robert Haas <rhaas@postgresql.org>; Nathan Bossart <bossartn@amazon.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, Jun 09, 2018 at 01:35:19PM -0700, David G. Johnston wrote:
> On Fri, May 11, 2018 at 8:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
>
> """
> Also, if any table mentioned in VACUUM uses a column list, then ANALYZE
> keyword must be supplied; previously ANALYZE was implied in such cases.
> """
>
> Should that be mentioned in the compatibility notes?
+1
Note also from 921059bd66c7fb1230c705d3b1a65940800c4cbb
This is okay in v10 but rejected in v11b1:
postgres=# VACUUM ANALYZE VERBOSE t;
ERROR: syntax error at or near "VERBOSE"
Justin
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-16 12:56 Darafei "Komяpa" Praliaskouski <me@komzpa.net>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Darafei "Komяpa" Praliaskouski @ 2018-06-16 12:56 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andrey Borodin <x4mmm@yandex-team.ru>; PostgreSQL-development <pgsql-hackers@postgresql.org>
>
> > I'm not sure it is usefull in release notes since it is more about API,
> and not
> > user-facing change. Just in case.
> > GiST opclasses now can omit compress and decompress functions. If
> compress
> > function is omited, IndexOnlyScan is enabled for opclass without any
> extra
> > change.
> > https://github.com/postgres/postgres/commit/
> > d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
>
> Uh, we do have this for SP-GiST:
>
> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
>
> I am unclear how far downt the API stack I should go in documenting
> changes like this.
>
It is also a bit misleading - the idea in that change is that now index
representation can be a lossy version of actual data type (a box instead of
polygon as a referende, so a changelog entry can tell "Allow SP-GiST index
creation for polygon datatype."). There is no "decompression" for such
thing. "compression" sounds like gzip for me in user-facing context.
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-19 09:15 Alexander Korotkov <a.korotkov@postgrespro.ru>
parent: Darafei "Komяpa" Praliaskouski <me@komzpa.net>
0 siblings, 1 reply; 181+ messages in thread
From: Alexander Korotkov @ 2018-06-19 09:15 UTC (permalink / raw)
To: Darafei Praliaskouski <me@komzpa.net>; +Cc: Bruce Momjian <bruce@momjian.us>; Andrey Borodin <x4mmm@yandex-team.ru>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
<me@komzpa.net> wrote:
>>
>> > I'm not sure it is usefull in release notes since it is more about API, and not
>> > user-facing change. Just in case.
>> > GiST opclasses now can omit compress and decompress functions. If compress
>> > function is omited, IndexOnlyScan is enabled for opclass without any extra
>> > change.
>> > https://github.com/postgres/postgres/commit/
>> > d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
>>
>> Uh, we do have this for SP-GiST:
>>
>> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
>> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
>>
>> I am unclear how far downt the API stack I should go in documenting
>> changes like this.
>
>
> It is also a bit misleading - the idea in that change is that now index representation can be a lossy version of actual data type (a box instead of polygon as a referende, so a changelog entry can tell "Allow SP-GiST index creation for polygon datatype."). There is no "decompression" for such thing. "compression" sounds like gzip for me in user-facing context.
+1 that current wording looks confusing. But I think we need to
highlight that we have general SP-GiST improvement, not just support
for particular datatype. So, I propose following wording: "Allow
SP-GiST to use lossy representation of leaf keys, and add SP-GiST
support for polygon type using that".
I would also like to highlight, that there is a set of typos found my
Liudmila Mantrova in documentation including release notes [1]. As
you know, I'm not native English speaker, but fixes proposed by
Liudmila looks correct for me.
1. https://www.postgresql.org/message-id/275fc450-bbc9-a715-04bb-3b7104fecfcd%40postgrespro.ru
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-19 10:40 Alexander Korotkov <a.korotkov@postgrespro.ru>
parent: Alexander Korotkov <a.korotkov@postgrespro.ru>
0 siblings, 2 replies; 181+ messages in thread
From: Alexander Korotkov @ 2018-06-19 10:40 UTC (permalink / raw)
To: Darafei Praliaskouski <me@komzpa.net>; +Cc: Bruce Momjian <bruce@momjian.us>; Andrey Borodin <x4mmm@yandex-team.ru>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
> <me@komzpa.net> wrote:
> >>
> >> > I'm not sure it is usefull in release notes since it is more about API, and not
> >> > user-facing change. Just in case.
> >> > GiST opclasses now can omit compress and decompress functions. If compress
> >> > function is omited, IndexOnlyScan is enabled for opclass without any extra
> >> > change.
> >> > https://github.com/postgres/postgres/commit/
> >> > d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
> >>
> >> Uh, we do have this for SP-GiST:
> >>
> >> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
> >> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
> >>
> >> I am unclear how far downt the API stack I should go in documenting
> >> changes like this.
> >
> >
> > It is also a bit misleading - the idea in that change is that now index representation can be a lossy version of actual data type (a box instead of polygon as a referende, so a changelog entry can tell "Allow SP-GiST index creation for polygon datatype."). There is no "decompression" for such thing. "compression" sounds like gzip for me in user-facing context.
>
> +1 that current wording looks confusing. But I think we need to
> highlight that we have general SP-GiST improvement, not just support
> for particular datatype. So, I propose following wording: "Allow
> SP-GiST to use lossy representation of leaf keys, and add SP-GiST
> support for polygon type using that".
Oh, I missed that we have separate release notes entry for polygons
indexing. Then second part of sentence isn't needed, it should be
just "Allow SP-GiST to use lossy representation of leaf keys". If no
objections, I'm going to commit that altogether with fixes by
Liudmila.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
spgist-compress-release-notes.patch (application/octet-stream, 483B) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 7599c6f7a7..cb37adc466 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -933,7 +933,7 @@ same commits as above
-->
<para>
- Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
+ Allow SP-GiST to use lossy representation of leaf keys (Teodor Sigaev,
Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
</para>
* Re: Postgres 11 release notes
@ 2018-06-19 15:18 Daniel Gustafsson <daniel@yesql.se>
parent: Alexander Korotkov <a.korotkov@postgrespro.ru>
1 sibling, 1 reply; 181+ messages in thread
From: Daniel Gustafsson @ 2018-06-19 15:18 UTC (permalink / raw)
To: Alexander Korotkov <a.korotkov@postgrespro.ru>; +Cc: Darafei Praliaskouski <me@komzpa.net>; Bruce Momjian <bruce@momjian.us>; Andrey Borodin <x4mmm@yandex-team.ru>; pgsql-hackers <pgsql-hackers@postgresql.org>
> On 19 Jun 2018, at 12:40, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
>
> On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
>> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
>> <me@komzpa.net> wrote:
>>>>
>>>>> I'm not sure it is usefull in release notes since it is more about API, and not
>>>>> user-facing change. Just in case.
>>>>> GiST opclasses now can omit compress and decompress functions. If compress
>>>>> function is omited, IndexOnlyScan is enabled for opclass without any extra
>>>>> change.
>>>>> https://github.com/postgres/postgres/commit/
>>>>> d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
>>>>
>>>> Uh, we do have this for SP-GiST:
>>>>
>>>> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
>>>> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
>>>>
>>>> I am unclear how far downt the API stack I should go in documenting
>>>> changes like this.
>>>
>>>
>>> It is also a bit misleading - the idea in that change is that now index representation can be a lossy version of actual data type (a box instead of polygon as a referende, so a changelog entry can tell "Allow SP-GiST index creation for polygon datatype."). There is no "decompression" for such thing. "compression" sounds like gzip for me in user-facing context.
>>
>> +1 that current wording looks confusing. But I think we need to
>> highlight that we have general SP-GiST improvement, not just support
>> for particular datatype. So, I propose following wording: "Allow
>> SP-GiST to use lossy representation of leaf keys, and add SP-GiST
>> support for polygon type using that".
>
> Oh, I missed that we have separate release notes entry for polygons
> indexing. Then second part of sentence isn't needed, it should be
> just "Allow SP-GiST to use lossy representation of leaf keys". If no
> objections, I'm going to commit that altogether with fixes by
> Liudmila.
Speaking of typos, I think I spotted two more: s/features is/feature is/.
Fixed in the attached diff.
cheers ./daniel
Attachments:
relnotes11typo.diff (application/octet-stream, 940B) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 7599c6f7a7..de74b33b87 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -629,7 +629,7 @@ Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
</para>
<para>
- This features is disabled by default
+ This feature is disabled by default
but can be enabled by changing <link
linkend="guc-enable-partitionwise-join"><varname>enable_partitionwise_join</varname></link>.
</para>
@@ -647,7 +647,7 @@ Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
</para>
<para>
- This features is disabled by default
+ This feature is disabled by default
but can be enabled by changing <link
linkend="guc-enable-partitionwise-aggregate"><varname>enable_partitionwise_aggregate</varname></link>.
</para>
* Re: Postgres 11 release notes
@ 2018-06-19 15:37 Alexander Korotkov <a.korotkov@postgrespro.ru>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 0 replies; 181+ messages in thread
From: Alexander Korotkov @ 2018-06-19 15:37 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Darafei Praliaskouski <me@komzpa.net>; Bruce Momjian <bruce@momjian.us>; Andrey Borodin <x4mmm@yandex-team.ru>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Tue, Jun 19, 2018 at 6:18 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> > On 19 Jun 2018, at 12:40, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
> >
> > On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
> > <a.korotkov@postgrespro.ru> wrote:
> >> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
> >> <me@komzpa.net> wrote:
> >>>>
> >>>>> I'm not sure it is usefull in release notes since it is more about API, and not
> >>>>> user-facing change. Just in case.
> >>>>> GiST opclasses now can omit compress and decompress functions. If compress
> >>>>> function is omited, IndexOnlyScan is enabled for opclass without any extra
> >>>>> change.
> >>>>> https://github.com/postgres/postgres/commit/
> >>>>> d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
> >>>>
> >>>> Uh, we do have this for SP-GiST:
> >>>>
> >>>> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
> >>>> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
> >>>>
> >>>> I am unclear how far downt the API stack I should go in documenting
> >>>> changes like this.
> >>>
> >>>
> >>> It is also a bit misleading - the idea in that change is that now index representation can be a lossy version of actual data type (a box instead of polygon as a referende, so a changelog entry can tell "Allow SP-GiST index creation for polygon datatype."). There is no "decompression" for such thing. "compression" sounds like gzip for me in user-facing context.
> >>
> >> +1 that current wording looks confusing. But I think we need to
> >> highlight that we have general SP-GiST improvement, not just support
> >> for particular datatype. So, I propose following wording: "Allow
> >> SP-GiST to use lossy representation of leaf keys, and add SP-GiST
> >> support for polygon type using that".
> >
> > Oh, I missed that we have separate release notes entry for polygons
> > indexing. Then second part of sentence isn't needed, it should be
> > just "Allow SP-GiST to use lossy representation of leaf keys". If no
> > objections, I'm going to commit that altogether with fixes by
> > Liudmila.
>
> Speaking of typos, I think I spotted two more: s/features is/feature is/.
> Fixed in the attached diff.
Committed, thanks!
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-21 12:56 Alexander Korotkov <a.korotkov@postgrespro.ru>
parent: Alexander Korotkov <a.korotkov@postgrespro.ru>
1 sibling, 1 reply; 181+ messages in thread
From: Alexander Korotkov @ 2018-06-21 12:56 UTC (permalink / raw)
To: Darafei Praliaskouski <me@komzpa.net>; +Cc: Bruce Momjian <bruce@momjian.us>; Andrey Borodin <x4mmm@yandex-team.ru>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Tue, Jun 19, 2018 at 1:40 PM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
> > On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
> > <me@komzpa.net> wrote:
> > >>
> > >> > I'm not sure it is usefull in release notes since it is more about API, and not
> > >> > user-facing change. Just in case.
> > >> > GiST opclasses now can omit compress and decompress functions. If compress
> > >> > function is omited, IndexOnlyScan is enabled for opclass without any extra
> > >> > change.
> > >> > https://github.com/postgres/postgres/commit/
> > >> > d3a4f89d8a3e500bd7c0b7a8a8a5ce1b47859128
> > >>
> > >> Uh, we do have this for SP-GiST:
> > >>
> > >> Allow SP-GiST indexes to optionally use compression (Teodor Sigaev,
> > >> Heikki Linnakangas, Alexander Korotkov, Nikita Glukhov)
> > >>
> > >> I am unclear how far downt the API stack I should go in documenting
> > >> changes like this.
> > >
> > >
> > > It is also a bit misleading - the idea in that change is that now index representation can be a lossy version of actual data type (a box instead of polygon as a referende, so a changelog entry can tell "Allow SP-GiST index creation for polygon datatype."). There is no "decompression" for such thing. "compression" sounds like gzip for me in user-facing context.
> >
> > +1 that current wording looks confusing. But I think we need to
> > highlight that we have general SP-GiST improvement, not just support
> > for particular datatype. So, I propose following wording: "Allow
> > SP-GiST to use lossy representation of leaf keys, and add SP-GiST
> > support for polygon type using that".
>
> Oh, I missed that we have separate release notes entry for polygons
> indexing. Then second part of sentence isn't needed, it should be
> just "Allow SP-GiST to use lossy representation of leaf keys". If no
> objections, I'm going to commit that altogether with fixes by
> Liudmila.
Wording improvement is pushed. Typo fixes are already pushed by Magnus.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-30 18:11 Brad DeJong <bpd0018@gmail.com>
parent: Alexander Korotkov <a.korotkov@postgrespro.ru>
0 siblings, 1 reply; 181+ messages in thread
From: Brad DeJong @ 2018-06-30 18:11 UTC (permalink / raw)
To: pgsql-hackers <pgsql-hackers@postgresql.org>; +Cc: Bruce Momjian <bruce@momjian.us>
I suggest the following edits for the PostgreSQL beta 2 release
announcement.
I did not provide the edits as a patch because I can't find the source of
/about/news/1867.
- This release contains ... as well as bug fixes that were reported ...
+ This release contains ... as well as fixes for bugs that were reported ...
- we do not advise for you to run
+ we do not advise you to run
or
+ we do not advise running
- CHANGES SINCE BETA 2
+ CHANGES SINCE BETA 1
- There have been many bug fixes for PostgreSQL 11 reported during
- the Beta 1 period and applied to the Beta 2 release. Several bug fixes
- reported for version 10 or earlier that also affected version 11 are
- included in the Beta 2 release.
+ Fixes for many of the bugs reported during the PostgreSQL 11 Beta 1
+ period have been applied to the Beta 2 release. Fixes for several bugs
+ reported for version 10 or earlier that affected version 11 have also
+ been included in the Beta 2 release.
or, if you prefer active voice
+ PostgreSQL 11 Beta 2 contains fixes for many of the bugs that were
+ reported during the Beta 1 period and for several bugs reported
+ for version 10 or earlier that affected version 11.
- ... eliminating a needless additional partition constraint checks ...
+ ... eliminating needless additional partition constraint checks ...
- including returning NULL if slot is not advanced
+ including returning NULL if the slot is not advanced
- Fix returning accurate results with ...
This phrasing makes it sound like you didn't want the accurate results so
you fixed them. :)
Not being familiar with the fix in question, I do not have a suggestion as
to how it should be rephrased.
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-30 18:48 Daniel Gustafsson <daniel@yesql.se>
parent: Brad DeJong <bpd0018@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Daniel Gustafsson @ 2018-06-30 18:48 UTC (permalink / raw)
To: Brad DeJong <bpd0018@gmail.com>; +Cc: pgsql-hackers <pgsql-hackers@postgresql.org>; Bruce Momjian <bruce@momjian.us>; pgsql-www
> On 30 Jun 2018, at 20:11, Brad DeJong <bpd0018@gmail.com> wrote:
>
> I suggest the following edits for the PostgreSQL beta 2 release announcement.
> I did not provide the edits as a patch because I can't find the source of /about/news/1867.
The news item is stored in the postgresql.org database, and not in the code, so
there is no file to patch. CC:ing -www where website changes are discussed.
cheers ./daniel
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-30 18:56 Jonathan S. Katz <jkatz@postgresql.org>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 181+ messages in thread
From: Jonathan S. Katz @ 2018-06-30 18:56 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Brad DeJong <bpd0018@gmail.com>; pgsql-hackers <pgsql-hackers@postgresql.org>; Bruce Momjian <bruce@momjian.us>; pgsql-www
> On Jun 30, 2018, at 2:48 PM, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> On 30 Jun 2018, at 20:11, Brad DeJong <bpd0018@gmail.com> wrote:
>>
>> I suggest the following edits for the PostgreSQL beta 2 release announcement.
>> I did not provide the edits as a patch because I can't find the source of /about/news/1867.
>
> The news item is stored in the postgresql.org database, and not in the code, so
> there is no file to patch. CC:ing -www where website changes are discussed.
The "CHANGES SINCE BETA 1” was applied earlier thanks to a separate report.
I applied wording fixes for the 3 bulleted items listed. I did not see any reason to
change the opening line as well as intro paragraph to the “CHANGES SINCE BETA 1”
section.
Thanks for reporting!
Jonathan
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-30 21:48 Yaroslav <ladayaroslav@yandex.ru>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 2 replies; 181+ messages in thread
From: Yaroslav @ 2018-06-30 21:48 UTC (permalink / raw)
To: pgsql-hackers@postgresql.org
Hello.
I've noticed the following in v11 release notes:
"Window functions now support all options shown in the SQL:2011 standard,
including RANGE distance PRECEDING/FOLLOWING, GROUPS mode, and frame
exclusion options"
But, as far as I see, IGNORE NULLS option for lead, lag, etc. is still not
supported. May be, the item could be reformulated?
--
WBR, Yaroslav Schekin
-----
WBR, Yaroslav Schekin.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-06-30 21:52 Tom Lane <tgl@sss.pgh.pa.us>
parent: Yaroslav <ladayaroslav@yandex.ru>
1 sibling, 1 reply; 181+ messages in thread
From: Tom Lane @ 2018-06-30 21:52 UTC (permalink / raw)
To: Yaroslav <ladayaroslav@yandex.ru>; +Cc: pgsql-hackers@postgresql.org
Yaroslav <ladayaroslav@yandex.ru> writes:
> I've noticed the following in v11 release notes:
> "Window functions now support all options shown in the SQL:2011 standard,
> including RANGE distance PRECEDING/FOLLOWING, GROUPS mode, and frame
> exclusion options"
> But, as far as I see, IGNORE NULLS option for lead, lag, etc. is still not
> supported. May be, the item could be reformulated?
Mmm, yeah, I suppose it should say "all framing options" rather than
implying that we've implemented every other window-related frammish
there is in the spec.
regards, tom lane
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-01 19:57 Jonathan S. Katz <jonathan.katz@excoventures.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 181+ messages in thread
From: Jonathan S. Katz @ 2018-07-01 19:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Yaroslav <ladayaroslav@yandex.ru>; pgsql-hackers@postgresql.org
> On Jun 30, 2018, at 5:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Yaroslav <ladayaroslav@yandex.ru> writes:
>> I've noticed the following in v11 release notes:
>> "Window functions now support all options shown in the SQL:2011 standard,
>> including RANGE distance PRECEDING/FOLLOWING, GROUPS mode, and frame
>> exclusion options"
>
>> But, as far as I see, IGNORE NULLS option for lead, lag, etc. is still not
>> supported. May be, the item could be reformulated?
>
> Mmm, yeah, I suppose it should say "all framing options" rather than
> implying that we've implemented every other window-related frammish
> there is in the spec.
+1. Attached patch that does exactly that.
Jonathan
Attachments:
0001-window-docs.patch (application/octet-stream, 928B) download
From 4aac9577b331cca8ebe4bf30e771384c372ca64a Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sun, 1 Jul 2018 15:55:37 -0400
Subject: [PATCH] Clarify support for new window function capabilities added in
v11.
---
doc/src/sgml/release-11.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 51a5501482..1b21794e5a 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -92,7 +92,7 @@
<listitem>
<para>
- Window functions now support all options shown in the SQL:2011
+ Window functions now support all framing options shown in the SQL:2011
standard, including <literal>RANGE <replaceable>distance</replaceable>
PRECEDING/FOLLOWING</literal>, <literal>GROUPS</literal> mode, and
frame exclusion options
--
2.14.3 (Apple Git-98)
=
* Re: Postgres 11 release notes
@ 2018-07-09 05:18 Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Tatsuro Yamada @ 2018-07-09 05:18 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org; bruce@momjian.us
Hi Bruce,
> I expect a torrent of feedback.;-)
Could you add this fix to the release note because this change affects
an extension developer using the hook function.
It would be better to know the change by reading the release note, not compilation error.
<!--
2017-01-11 [4d41b2e09] Add QueryEnvironment to ExplainOneQuery_hook's parameter list.
-->
<para>
Add QueryEnvironment to ExplainOneQuery_hook's parameter list
(Tatsuro Yamada, Thomas Munro)
</para>
Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
I guess "E.1.3.11. Source Code" or "E.1.3.12. Additional Modules" sections are
suitable for putting the message in the release note.
Thanks,
Tatsuro Yamada
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-09 05:28 Andres Freund <andres@anarazel.de>
parent: Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-07-09 05:28 UTC (permalink / raw)
To: Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>; +Cc: pgsql-hackers@lists.postgresql.org; bruce@momjian.us
On 2018-07-09 14:18:14 +0900, Tatsuro Yamada wrote:
> Hi Bruce,
>
> > I expect a torrent of feedback.;-)
>
> Could you add this fix to the release note because this change affects
> an extension developer using the hook function.
> It would be better to know the change by reading the release note, not compilation error.
>
> <!--
> 2017-01-11 [4d41b2e09] Add QueryEnvironment to ExplainOneQuery_hook's parameter list.
> -->
> <para>
> Add QueryEnvironment to ExplainOneQuery_hook's parameter list
> (Tatsuro Yamada, Thomas Munro)
> </para>
>
> Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
>
> I guess "E.1.3.11. Source Code" or "E.1.3.12. Additional Modules" sections are
> suitable for putting the message in the release note.
We adapt plenty of functions signatures without listing them
individually in the release notes. I don't think randomly selecting one
relatively uncommonly used hook is a good way to attack that.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-09 14:36 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-07-09 14:36 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>; pgsql-hackers@lists.postgresql.org
On Sun, Jul 8, 2018 at 10:28:15PM -0700, Andres Freund wrote:
> On 2018-07-09 14:18:14 +0900, Tatsuro Yamada wrote:
> > Hi Bruce,
> >
> > > I expect a torrent of feedback.;-)
> >
> > Could you add this fix to the release note because this change affects
> > an extension developer using the hook function.
> > It would be better to know the change by reading the release note, not compilation error.
> >
> > <!--
> > 2017-01-11 [4d41b2e09] Add QueryEnvironment to ExplainOneQuery_hook's parameter list.
> > -->
> > <para>
> > Add QueryEnvironment to ExplainOneQuery_hook's parameter list
> > (Tatsuro Yamada, Thomas Munro)
> > </para>
> >
> > Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
> >
> > I guess "E.1.3.11. Source Code" or "E.1.3.12. Additional Modules" sections are
> > suitable for putting the message in the release note.
>
> We adapt plenty of functions signatures without listing them
> individually in the release notes. I don't think randomly selecting one
> relatively uncommonly used hook is a good way to attack that.
Agreed. Ideally we would have a wiki page that lists _all_ the hooks,
and what release they were added.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-09 14:52 David Fetter <david@fetter.org>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 181+ messages in thread
From: David Fetter @ 2018-07-09 14:52 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>; pgsql-hackers@lists.postgresql.org
On Mon, Jul 09, 2018 at 10:36:30AM -0400, Bruce Momjian wrote:
> On Sun, Jul 8, 2018 at 10:28:15PM -0700, Andres Freund wrote:
> > On 2018-07-09 14:18:14 +0900, Tatsuro Yamada wrote:
> > > Hi Bruce,
> > >
> > > > I expect a torrent of feedback.;-)
> > >
> > > Could you add this fix to the release note because this change affects
> > > an extension developer using the hook function.
> > > It would be better to know the change by reading the release note, not compilation error.
> > >
> > > <!--
> > > 2017-01-11 [4d41b2e09] Add QueryEnvironment to ExplainOneQuery_hook's parameter list.
> > > -->
> > > <para>
> > > Add QueryEnvironment to ExplainOneQuery_hook's parameter list
> > > (Tatsuro Yamada, Thomas Munro)
> > > </para>
> > >
> > > Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
> > >
> > > I guess "E.1.3.11. Source Code" or "E.1.3.12. Additional Modules" sections are
> > > suitable for putting the message in the release note.
> >
> > We adapt plenty of functions signatures without listing them
> > individually in the release notes. I don't think randomly selecting one
> > relatively uncommonly used hook is a good way to attack that.
>
> Agreed. Ideally we would have a wiki page that lists _all_ the hooks,
> and what release they were added.
If we're talking about ideals, all our public APIs including the hooks
should be in the official documentation and have man pages.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-10 01:09 Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
parent: David Fetter <david@fetter.org>
1 sibling, 0 replies; 181+ messages in thread
From: Tatsuro Yamada @ 2018-07-10 01:09 UTC (permalink / raw)
To: David Fetter <david@fetter.org>; Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@lists.postgresql.org
On 2018/07/09 23:52, David Fetter wrote:
> On Mon, Jul 09, 2018 at 10:36:30AM -0400, Bruce Momjian wrote:
>> On Sun, Jul 8, 2018 at 10:28:15PM -0700, Andres Freund wrote:
>>> On 2018-07-09 14:18:14 +0900, Tatsuro Yamada wrote:
>>>> Hi Bruce,
>>>>
>>>>> I expect a torrent of feedback.;-)
>>>>
>>>> Could you add this fix to the release note because this change affects
>>>> an extension developer using the hook function.
>>>> It would be better to know the change by reading the release note, not compilation error.
>>>>
>>>> <!--
>>>> 2017-01-11 [4d41b2e09] Add QueryEnvironment to ExplainOneQuery_hook's parameter list.
>>>> -->
>>>> <para>
>>>> Add QueryEnvironment to ExplainOneQuery_hook's parameter list
>>>> (Tatsuro Yamada, Thomas Munro)
>>>> </para>
>>>>
>>>> Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
>>>>
>>>> I guess "E.1.3.11. Source Code" or "E.1.3.12. Additional Modules" sections are
>>>> suitable for putting the message in the release note.
>>>
>>> We adapt plenty of functions signatures without listing them
>>> individually in the release notes. I don't think randomly selecting one
>>> relatively uncommonly used hook is a good way to attack that.
>>
>> Agreed. Ideally we would have a wiki page that lists _all_ the hooks,
>> and what release they were added.
Did you mean the page is pdf file?
If so, it is not updated from 2012 because it's a presentation material.
I couldn't find other lists by using "hooks" in search box on wiki.
https://wiki.postgresql.org/images/e/e3/Hooks_in_postgresql.pdf
> If we're talking about ideals, all our public APIs including the hooks
> should be in the official documentation and have man pages.
I think so too.
It is useful information for newbe developer and extension developer.
Thanks,
Tatsuro Yamada
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-10 01:17 Andres Freund <andres@anarazel.de>
parent: David Fetter <david@fetter.org>
1 sibling, 0 replies; 181+ messages in thread
From: Andres Freund @ 2018-07-10 01:17 UTC (permalink / raw)
To: David Fetter <david@fetter.org>; +Cc: Bruce Momjian <bruce@momjian.us>; Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>; pgsql-hackers@lists.postgresql.org
On 2018-07-09 16:52:11 +0200, David Fetter wrote:
> On Mon, Jul 09, 2018 at 10:36:30AM -0400, Bruce Momjian wrote:
> > On Sun, Jul 8, 2018 at 10:28:15PM -0700, Andres Freund wrote:
> > > On 2018-07-09 14:18:14 +0900, Tatsuro Yamada wrote:
> > > > Hi Bruce,
> > > >
> > > > > I expect a torrent of feedback.;-)
> > > >
> > > > Could you add this fix to the release note because this change affects
> > > > an extension developer using the hook function.
> > > > It would be better to know the change by reading the release note, not compilation error.
> > > >
> > > > <!--
> > > > 2017-01-11 [4d41b2e09] Add QueryEnvironment to ExplainOneQuery_hook's parameter list.
> > > > -->
> > > > <para>
> > > > Add QueryEnvironment to ExplainOneQuery_hook's parameter list
> > > > (Tatsuro Yamada, Thomas Munro)
> > > > </para>
> > > >
> > > > Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
> > > >
> > > > I guess "E.1.3.11. Source Code" or "E.1.3.12. Additional Modules" sections are
> > > > suitable for putting the message in the release note.
> > >
> > > We adapt plenty of functions signatures without listing them
> > > individually in the release notes. I don't think randomly selecting one
> > > relatively uncommonly used hook is a good way to attack that.
> >
> > Agreed. Ideally we would have a wiki page that lists _all_ the hooks,
> > and what release they were added.
>
> If we're talking about ideals, all our public APIs including the hooks
> should be in the official documentation and have man pages.
FWIW, at this point in time I'd pretty strenuously object to a rule
requiring all hooks / all public functions to be documented. I think the
development velocity penalty would be far greater than the benefit.
That's however *NOT* to say, that we shouldn't document individual API
that we expect to be somewhat stable / frequently externally used (say
the PL interface, C trigger interface).
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-07-12 15:14 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jonathan S. Katz <jonathan.katz@excoventures.com>
0 siblings, 0 replies; 181+ messages in thread
From: Tom Lane @ 2018-07-12 15:14 UTC (permalink / raw)
To: Jonathan S. Katz <jonathan.katz@excoventures.com>; +Cc: Yaroslav <ladayaroslav@yandex.ru>; pgsql-hackers@postgresql.org
"Jonathan S. Katz" <jonathan.katz@excoventures.com> writes:
> On Jun 30, 2018, at 5:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Mmm, yeah, I suppose it should say "all framing options" rather than
>> implying that we've implemented every other window-related frammish
>> there is in the spec.
> +1. Attached patch that does exactly that.
Pushed, thanks.
regards, tom lane
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-10 05:06 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Yaroslav <ladayaroslav@yandex.ru>
1 sibling, 1 reply; 181+ messages in thread
From: Masahiko Sawada @ 2018-08-10 05:06 UTC (permalink / raw)
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
I found that the release note says "Add pgtrgm function
strict_word_similarity() to compute the similarity of whole words" but
I think "pgtrgm" should be "pg_trgm". Attached patch fixes it.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachments:
fix_11_release_note.patch (application/octet-stream, 545B) download
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 9723bc2..b4a5379 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -2835,7 +2835,7 @@ same commits as above
-->
<para>
- Add <link linkend="pgtrgm"><application>pgtrgm</application></link>
+ Add <link linkend="pgtrgm"><application>pg_trgm</application></link>
function <function>strict_word_similarity()</function> to compute
the similarity of whole words (Alexander Korotkov)
</para>
* Re: Postgres 11 release notes
@ 2018-08-10 10:10 Alexander Korotkov <a.korotkov@postgrespro.ru>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 181+ messages in thread
From: Alexander Korotkov @ 2018-08-10 10:10 UTC (permalink / raw)
To: Sawada Masahiko <sawada.mshk@gmail.com>; +Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
On Fri, Aug 10, 2018 at 8:08 AM Masahiko Sawada <sawada.mshk@gmail.com>
wrote:
> I found that the release note says "Add pgtrgm function
> strict_word_similarity() to compute the similarity of whole words" but
> I think "pgtrgm" should be "pg_trgm". Attached patch fixes it.
>
Right. Pushed, thanks!
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-12 09:21 Adrien Nayrat <adrien.nayrat@anayrat.info>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Adrien Nayrat @ 2018-08-12 09:21 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
Hello,
It seems this feature is missing in releases notes ?
commit 1f6d515a67ec98194c23a5db25660856c9aab944
Author: Robert Haas <rhaas@postgresql.org>
Date: Mon Aug 21 14:43:01 2017 -0400
Push limit through subqueries to underlying sort, where possible.
Douglas Doole, reviewed by Ashutosh Bapat and by me. Minor formatting
change by me.
Discussion:
http://postgr.es/m/CADE5jYLuugnEEUsyW6Q_4mZFYTxHxaVCQmGAsF0yiY8ZDggi-w@mail.gmail.com
Regards,
Attachments:
signature.asc (application/pgp-signature, 487B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-13 00:10 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Alexander Korotkov <a.korotkov@postgrespro.ru>
0 siblings, 0 replies; 181+ messages in thread
From: Masahiko Sawada @ 2018-08-13 00:10 UTC (permalink / raw)
To: Alexander Korotkov <a.korotkov@postgrespro.ru>; +Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
On Fri, Aug 10, 2018 at 7:10 PM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Fri, Aug 10, 2018 at 8:08 AM Masahiko Sawada <sawada.mshk@gmail.com>
> wrote:
>>
>> I found that the release note says "Add pgtrgm function
>> strict_word_similarity() to compute the similarity of whole words" but
>> I think "pgtrgm" should be "pg_trgm". Attached patch fixes it.
>
>
> Right. Pushed, thanks!
>
Thank you!
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-25 18:41 Bruce Momjian <bruce@momjian.us>
parent: Adrien Nayrat <adrien.nayrat@anayrat.info>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-08-25 18:41 UTC (permalink / raw)
To: Adrien Nayrat <adrien.nayrat@anayrat.info>; +Cc: pgsql-hackers@lists.postgresql.org
On Sun, Aug 12, 2018 at 11:21:26AM +0200, Adrien Nayrat wrote:
> Hello,
>
> It seems this feature is missing in releases notes ?
>
> commit 1f6d515a67ec98194c23a5db25660856c9aab944
> Author: Robert Haas <rhaas@postgresql.org>
> Date: Mon Aug 21 14:43:01 2017 -0400
>
> Push limit through subqueries to underlying sort, where possible.
>
> Douglas Doole, reviewed by Ashutosh Bapat and by me. Minor formatting
> change by me.
>
> Discussion:
> http://postgr.es/m/CADE5jYLuugnEEUsyW6Q_4mZFYTxHxaVCQmGAsF0yiY8ZDggi-w@mail.gmail.com
I looked into this and it is usually a detail we don't have in the
release notes. It isn't generally interesting enough to user.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-25 18:42 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-08-25 18:42 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org,Bruce Momjian <bruce@momjian.us>; Adrien Nayrat <adrien.nayrat@anayrat.info>
On August 25, 2018 11:41:11 AM PDT, Bruce Momjian <bruce@momjian.us> wrote:
>On Sun, Aug 12, 2018 at 11:21:26AM +0200, Adrien Nayrat wrote:
>> Hello,
>>
>> It seems this feature is missing in releases notes ?
>>
>> commit 1f6d515a67ec98194c23a5db25660856c9aab944
>> Author: Robert Haas <rhaas@postgresql.org>
>> Date: Mon Aug 21 14:43:01 2017 -0400
>>
>> Push limit through subqueries to underlying sort, where possible.
>>
>> Douglas Doole, reviewed by Ashutosh Bapat and by me. Minor
>formatting
>> change by me.
>>
>> Discussion:
>>
>http://postgr.es/m/CADE5jYLuugnEEUsyW6Q_4mZFYTxHxaVCQmGAsF0yiY8ZDggi-w@mail.gmail.com
>
>I looked into this and it is usually a detail we don't have in the
>release notes. It isn't generally interesting enough to user.
This seems quite relevant. Both because it addresses concerns, but also can lead to a worse plan.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-25 18:47 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-08-25 18:47 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@lists.postgresql.org, Adrien Nayrat <adrien.nayrat@anayrat.info>
On Sat, Aug 25, 2018 at 11:42:35AM -0700, Andres Freund wrote:
>
>
> On August 25, 2018 11:41:11 AM PDT, Bruce Momjian <bruce@momjian.us> wrote:
> >On Sun, Aug 12, 2018 at 11:21:26AM +0200, Adrien Nayrat wrote:
> >> Hello,
> >>
> >> It seems this feature is missing in releases notes ?
> >>
> >> commit 1f6d515a67ec98194c23a5db25660856c9aab944
> >> Author: Robert Haas <rhaas@postgresql.org>
> >> Date: Mon Aug 21 14:43:01 2017 -0400
> >>
> >> Push limit through subqueries to underlying sort, where possible.
> >>
> >> Douglas Doole, reviewed by Ashutosh Bapat and by me. Minor
> >formatting
> >> change by me.
> >>
> >> Discussion:
> >>
> >http://postgr.es/m/CADE5jYLuugnEEUsyW6Q_4mZFYTxHxaVCQmGAsF0yiY8ZDggi-w@mail.gmail.com
> >
> >I looked into this and it is usually a detail we don't have in the
> >release notes. It isn't generally interesting enough to user.
>
> This seems quite relevant. Both because it addresses concerns, but also can lead to a worse plan.
Well, our normal logical is whether the average user would adjust their
behavior based on this change, or whether it is user visible. I thought
it was a contrived-enough query that this was not the case, but I would
be interested to hear what others think.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-25 19:17 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-08-25 19:17 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers@lists.postgresql.org, Adrien Nayrat <adrien.nayrat@anayrat.info>
Hi,
On 2018-08-25 14:47:20 -0400, Bruce Momjian wrote:
> Well, our normal logical is whether the average user would adjust their
> behavior based on this change, or whether it is user visible. I thought
> it was a contrived-enough query that this was not the case, but I would
> be interested to hear what others think.
I think that's less "our" logic and more yours, that has become
established because you've done most of the major release notes for a
long time. I'm not trying to say that that's wrong or anything, just
that a lot of those principles grew organically without explicit
decisions.
I also think that the need of userbase have shifted - it used to be that
a lot more people couldn't migrate to PG for lack of features, but these
days we have a much larger userbase that has to migrate from version to
version on a regular basis.
Planner changes, in my experience, are *the* major hurdle in doing so
(leaving aside things like the 8.3 casting changes), because they have
the potential to drastically change performance. In a largely
unpredictable way. So one of the first things you do after encountering
an issue while testing an issue during a migration, is to look through
the release notes whether that query could be affected by a documented
change.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-25 21:18 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-08-25 21:18 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@lists.postgresql.org, Adrien Nayrat <adrien.nayrat@anayrat.info>
On Sat, Aug 25, 2018 at 12:17:17PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-08-25 14:47:20 -0400, Bruce Momjian wrote:
> > Well, our normal logical is whether the average user would adjust their
> > behavior based on this change, or whether it is user visible. I thought
> > it was a contrived-enough query that this was not the case, but I would
> > be interested to hear what others think.
>
> I think that's less "our" logic and more yours, that has become
> established because you've done most of the major release notes for a
> long time. I'm not trying to say that that's wrong or anything, just
I don't do my work in a vacuum. My behavior is based on what feedback I
have gotten from the community on what to include/exclude.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-25 21:24 Peter Geoghegan <pg@bowt.ie>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Peter Geoghegan @ 2018-08-25 21:24 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Adrien Nayrat <adrien.nayrat@anayrat.info>
On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I think that's less "our" logic and more yours, that has become
>> established because you've done most of the major release notes for a
>> long time. I'm not trying to say that that's wrong or anything, just
>
> I don't do my work in a vacuum. My behavior is based on what feedback I
> have gotten from the community on what to include/exclude.
FWIW, I agree with what Andres said about planner changes and the release notes.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-08-26 11:23 Amit Kapila <amit.kapila16@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 0 replies; 181+ messages in thread
From: Amit Kapila @ 2018-08-26 11:23 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Adrien Nayrat <adrien.nayrat@anayrat.info>
On Sun, Aug 26, 2018 at 12:17 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Sat, Aug 25, 2018 at 11:42:35AM -0700, Andres Freund wrote:
> >
> >
> > On August 25, 2018 11:41:11 AM PDT, Bruce Momjian <bruce@momjian.us> wrote:
> > >On Sun, Aug 12, 2018 at 11:21:26AM +0200, Adrien Nayrat wrote:
> > >> Hello,
> > >>
> > >> It seems this feature is missing in releases notes ?
> > >>
> > >> commit 1f6d515a67ec98194c23a5db25660856c9aab944
> > >> Author: Robert Haas <rhaas@postgresql.org>
> > >> Date: Mon Aug 21 14:43:01 2017 -0400
> > >>
> > >> Push limit through subqueries to underlying sort, where possible.
> > >>
> > >> Douglas Doole, reviewed by Ashutosh Bapat and by me. Minor
> > >formatting
> > >> change by me.
> > >>
> > >> Discussion:
> > >>
> > >http://postgr.es/m/CADE5jYLuugnEEUsyW6Q_4mZFYTxHxaVCQmGAsF0yiY8ZDggi-w@mail.gmail.com
> > >
> > >I looked into this and it is usually a detail we don't have in the
> > >release notes. It isn't generally interesting enough to user.
> >
> > This seems quite relevant. Both because it addresses concerns, but also can lead to a worse plan.
+1.
>
> Well, our normal logical is whether the average user would adjust their
> behavior based on this change, or whether it is user visible.
>
In general, I think this is okay because otherwise providing a lot of
information which most users won't care doesn't serve any purpose.
OTOH, I think it is not easy to decide which features to ignore. I
think it won't be important to mention some of the code refactoring
commits or minor improvements in the code here and there, but we can't
say that about any of the performance or planner improvements. Sure,
we might not want to mention everything, but it is better we discuss
such features before ignoring it. I agree that it will be more work
for preparing release notes, but in the end, we might save some time
by not arguing later about which feature is important and which is
not.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-12 17:34 Michael Banck <michael.banck@credativ.de>
parent: Bruce Momjian <bruce@momjian.us>
22 siblings, 1 reply; 181+ messages in thread
From: Michael Banck @ 2018-09-12 17:34 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> I have committed the first draft of the Postgres 11 release notes. I
> will add more markup soon. You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
The first item of section 'E.1.3.10. Server Applications' is mine and
has this TODO (though maybe that should be better marked up?) text:
|IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT TEMPORARY?
So I guess we need to decide on that before release. The current doc is
AFAIK:
| This option causes the replication slot specified by the
| option <literal>--slot</literal> to be created before starting the
| backup. In this case, an error is raised if the slot already exists.
I guess it does not hurt to have something like "to be (permanently)
created before starting", but what do others think? Is it clear enough?
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-15 15:06 Jonathan S. Katz <jkatz@postgresql.org>
parent: Michael Banck <michael.banck@credativ.de>
0 siblings, 2 replies; 181+ messages in thread
From: Jonathan S. Katz @ 2018-09-15 15:06 UTC (permalink / raw)
To: Michael Banck <michael.banck@credativ.de>; Bruce Momjian <bruce@momjian.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
On 9/12/18 1:34 PM, Michael Banck wrote:
> Hi,
>
> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
>> I have committed the first draft of the Postgres 11 release notes. I
>> will add more markup soon. You can view the most current version here:
>>
>> http://momjian.us/pgsql_docs/release-11.html
>
> The first item of section 'E.1.3.10. Server Applications' is mine and
> has this TODO (though maybe that should be better marked up?) text:
>
> |IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT TEMPORARY?
>
> So I guess we need to decide on that before release. The current doc is
> AFAIK:
>
> | This option causes the replication slot specified by the
> | option <literal>--slot</literal> to be created before starting the
> | backup. In this case, an error is raised if the slot already exists.
>
> I guess it does not hurt to have something like "to be (permanently)
> created before starting", but what do others think? Is it clear enough?
Attached are two patches.
The first modifies the major improvements section to align with what we
have discovered during the beta period + the general advocacy push. It
also modifies the "last updated date" + narrows down a prospective
release month.
The second modifies/removes the questions/placeholders in the release
notes, such as Michael's comment above (which I agreed with and added a
one sentence explanation after).
Thanks,
Jonathan
Attachments: download all (3 files, .tar.gz)
0001-Updates-to-major-improvements-section-of-release-not.patch (text/plain, 4.0K) download
From 2733f0df599aeda48408a3d27b796e36fbdd6fc3 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 10:43:44 -0400
Subject: [PATCH 1/2] Updates to major improvements section of release notes.
---
doc/src/sgml/release-11.sgml | 47 ++++++++++++++++++++++++++++++--------------
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 684d34c091..9ed34e72e8 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -6,7 +6,7 @@
<formalpara>
<title>Release date:</title>
- <para>2018-??-?? (CURRENT AS OF 2018-07-30)</para>
+ <para>2018-10-?? (CURRENT AS OF 2018-09-20)</para>
</formalpara>
<sect2>
@@ -22,11 +22,11 @@
<listitem>
<para>
- Major improvements to partitioning:
+ Improvements to partitioning functionality, including:
<itemizedlist>
<listitem>
<para>
- Partitioning by a hash key
+ Partitioning by a hash key (a.k.a. "hash partitioning")
</para>
</listitem>
<listitem>
@@ -37,9 +37,8 @@
</listitem>
<listitem>
<para>
- Improved <command>SELECT</command> query performance due to
- enhanced partition elimination during query processing and
- execution
+ Improved <command>SELECT</command> performance from enhanced partition
+ elimination strategies during query processing and execution
</para>
</listitem>
<listitem>
@@ -48,29 +47,37 @@
KEY</literal>, indexes, and triggers on partitioned tables
</para>
</listitem>
+ <listitem>
+ <para>
+ Having a "default" partition for storing data that does not match a
+ partition key
+ </para>
+ </listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
- Improvements to parallelism:
+ Improvements to parallelism, including:
<itemizedlist>
<listitem>
<para>
- Parallelized hash joins
+ B-tree indexes can now be built in parallel with
+ <command>CREATE INDEX</command>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE INDEX</command> for B-tree indexes
+ Parallelized <command>CREATE TABLE .. AS</command>,
+ <command>CREATE MATERIALIZED VIEW</command>, and certain
+ queries using <literal>UNION</literal>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE TABLE .. AS</command>,
- <command>CREATE MATERIALIZED VIEW</command>, and certain
- queries using <literal>UNION</literal>
+ Performance improvements for parallelized hash joins and parallelized
+ sequential scans
</para>
</listitem>
</itemizedlist>
@@ -79,14 +86,17 @@
<listitem>
<para>
- SQL stored procedures, with support for embedded transactions
+ SQL stored procedures that support embedded transactions. Stored
+ procedures can be created with <link linkend="sql-createprocedure">
+ <command>CREATE PROCEDURE</command></link> and executed with
+ <link linkend="sql-call"><command>CALL</command></link>
</para>
</listitem>
<listitem>
<para>
- JIT compilation of some SQL code, including support for fast evaluation
- of expressions
+ Introduction of <link linkend="jit">just-in-time</link> (JIT) compilation
+ during query execution
</para>
</listitem>
@@ -99,6 +109,13 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ Covering indexes, which can be utilized using the
+ <literal>INCLUDE</literal> clause of <command>CREATE INDEX</command>
+ </para>
+ </listitem>
+
<listitem>
<para>
Many other useful performance improvements, including making
--
2.14.3 (Apple Git-98)
0002-Remove-or-modify-placeholders-for-v11-release-notes.patch (text/plain, 2.6K) download
From feb08e3747e5dc043e21b60e9e681f44a0562896 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 11:01:35 -0400
Subject: [PATCH 2/2] Remove or modify placeholders for v11 release notes.
---
doc/src/sgml/release-11.sgml | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 9ed34e72e8..e8af023140 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -196,10 +196,6 @@
would be dumped without such specifications if the database locale
and encoding matched the old cluster's defaults.
</para>
-
- <para>
- DID I GET EVERYTHING?
- </para>
</listitem>
<listitem>
@@ -614,8 +610,7 @@
The new command <link linkend="sql-alterindex"><command>ALTER
INDEX ATTACH PARTITION</command></link> allows indexes to be
attached to partitions. This does not behave as a global index
- since the contents are private to each index. WARN WHEN USING
- AN EXISTING INDEX?
+ since the contents are private to each index.
</para>
</listitem>
@@ -924,7 +919,7 @@ same commits as above
</para>
<para>
- This reduces the likelihood of serialization conflicts. ACCURATE?
+ This reduces the likelihood of serialization conflicts.
</para>
</listitem>
@@ -1991,7 +1986,6 @@ same commits as above
<command>CALL</command>s or in nested PL/pgSQL DO and
<command>CALL</command> blocks that only contain other PL/pgSQL
<command>DO</command> and <command>CALL</command> blocks.
- ACCURATE?
</para>
</listitem>
@@ -2414,12 +2408,8 @@ same commits as above
The option <option>--create-slot</option> creates
the named replication slot (<option>--slot</option>)
when the <acronym>WAL</acronym> streaming method
- (<option>--wal-method=stream</option>) is used.
- </para>
-
- <para>
- IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
- TEMPORARY?
+ (<option>--wal-method=stream</option>) is used. The replication slot is
+ available until it is explicitly dropped.
</para>
</listitem>
@@ -2915,7 +2905,8 @@ same commits as above
</para>
<para>
- This is useful for KNN-GiST searches. HOW?
+ This is useful for KNN-GiST searches when looking for coordinates in
+ descending order.
</para>
</listitem>
--
2.14.3 (Apple Git-98)
* Re: Postgres 11 release notes
@ 2018-09-16 15:14 Bruce Momjian <bruce@momjian.us>
parent: Jonathan S. Katz <jkatz@postgresql.org>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-09-16 15:14 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, Sep 15, 2018 at 11:06:04AM -0400, Jonathan Katz wrote:
> <listitem>
> <para>
> - Partitioning by a hash key
> + Partitioning by a hash key (a.k.a. "hash partitioning")
I question whether a.k.a (also known as) is familiar enough to our
readers to appear in the releaes notes. I think the "a.k.a." can be
simply removed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-16 15:17 Jonathan S. Katz <jkatz@postgresql.org>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Jonathan S. Katz @ 2018-09-16 15:17 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 9/16/18 11:14 AM, Bruce Momjian wrote:
> On Sat, Sep 15, 2018 at 11:06:04AM -0400, Jonathan Katz wrote:
>> <listitem>
>> <para>
>> - Partitioning by a hash key
>> + Partitioning by a hash key (a.k.a. "hash partitioning")
>
> I question whether a.k.a (also known as) is familiar enough to our
> readers to appear in the releaes notes. I think the "a.k.a." can be
> simply removed.
Fine by me. I've reattached the patches.
Thanks,
Jonathan
Attachments: download all (3 files, .tar.gz)
0001-Updates-to-major-improvements-section-of-release-not.patch (text/plain, 3.8K) download
From c0a40e7831b19f75178a45d8db00f5e91d606e33 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 10:43:44 -0400
Subject: [PATCH 1/2] Updates to major improvements section of release notes.
---
doc/src/sgml/release-11.sgml | 45 ++++++++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 684d34c091..f81dd929e3 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -6,7 +6,7 @@
<formalpara>
<title>Release date:</title>
- <para>2018-??-?? (CURRENT AS OF 2018-07-30)</para>
+ <para>2018-10-?? (CURRENT AS OF 2018-09-20)</para>
</formalpara>
<sect2>
@@ -22,7 +22,7 @@
<listitem>
<para>
- Major improvements to partitioning:
+ Improvements to partitioning functionality, including:
<itemizedlist>
<listitem>
<para>
@@ -37,9 +37,8 @@
</listitem>
<listitem>
<para>
- Improved <command>SELECT</command> query performance due to
- enhanced partition elimination during query processing and
- execution
+ Improved <command>SELECT</command> performance from enhanced partition
+ elimination strategies during query processing and execution
</para>
</listitem>
<listitem>
@@ -48,29 +47,37 @@
KEY</literal>, indexes, and triggers on partitioned tables
</para>
</listitem>
+ <listitem>
+ <para>
+ Having a "default" partition for storing data that does not match a
+ partition key
+ </para>
+ </listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
- Improvements to parallelism:
+ Improvements to parallelism, including:
<itemizedlist>
<listitem>
<para>
- Parallelized hash joins
+ B-tree indexes can now be built in parallel with
+ <command>CREATE INDEX</command>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE INDEX</command> for B-tree indexes
+ Parallelized <command>CREATE TABLE .. AS</command>,
+ <command>CREATE MATERIALIZED VIEW</command>, and certain
+ queries using <literal>UNION</literal>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE TABLE .. AS</command>,
- <command>CREATE MATERIALIZED VIEW</command>, and certain
- queries using <literal>UNION</literal>
+ Performance improvements for parallelized hash joins and parallelized
+ sequential scans
</para>
</listitem>
</itemizedlist>
@@ -79,14 +86,17 @@
<listitem>
<para>
- SQL stored procedures, with support for embedded transactions
+ SQL stored procedures that support embedded transactions. Stored
+ procedures can be created with <link linkend="sql-createprocedure">
+ <command>CREATE PROCEDURE</command></link> and executed with
+ <link linkend="sql-call"><command>CALL</command></link>
</para>
</listitem>
<listitem>
<para>
- JIT compilation of some SQL code, including support for fast evaluation
- of expressions
+ Introduction of <link linkend="jit">just-in-time</link> (JIT) compilation
+ during query execution
</para>
</listitem>
@@ -99,6 +109,13 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ Covering indexes, which can be utilized using the
+ <literal>INCLUDE</literal> clause of <command>CREATE INDEX</command>
+ </para>
+ </listitem>
+
<listitem>
<para>
Many other useful performance improvements, including making
--
2.14.3 (Apple Git-98)
0002-Remove-or-modify-placeholders-for-v11-release-notes.patch (text/plain, 2.6K) download
From 5d86d059faa3a85626acdddf8429a197cc787a60 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 11:01:35 -0400
Subject: [PATCH 2/2] Remove or modify placeholders for v11 release notes.
---
doc/src/sgml/release-11.sgml | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index f81dd929e3..700fd02090 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -196,10 +196,6 @@
would be dumped without such specifications if the database locale
and encoding matched the old cluster's defaults.
</para>
-
- <para>
- DID I GET EVERYTHING?
- </para>
</listitem>
<listitem>
@@ -614,8 +610,7 @@
The new command <link linkend="sql-alterindex"><command>ALTER
INDEX ATTACH PARTITION</command></link> allows indexes to be
attached to partitions. This does not behave as a global index
- since the contents are private to each index. WARN WHEN USING
- AN EXISTING INDEX?
+ since the contents are private to each index.
</para>
</listitem>
@@ -924,7 +919,7 @@ same commits as above
</para>
<para>
- This reduces the likelihood of serialization conflicts. ACCURATE?
+ This reduces the likelihood of serialization conflicts.
</para>
</listitem>
@@ -1991,7 +1986,6 @@ same commits as above
<command>CALL</command>s or in nested PL/pgSQL DO and
<command>CALL</command> blocks that only contain other PL/pgSQL
<command>DO</command> and <command>CALL</command> blocks.
- ACCURATE?
</para>
</listitem>
@@ -2414,12 +2408,8 @@ same commits as above
The option <option>--create-slot</option> creates
the named replication slot (<option>--slot</option>)
when the <acronym>WAL</acronym> streaming method
- (<option>--wal-method=stream</option>) is used.
- </para>
-
- <para>
- IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
- TEMPORARY?
+ (<option>--wal-method=stream</option>) is used. The replication slot is
+ available until it is explicitly dropped.
</para>
</listitem>
@@ -2915,7 +2905,8 @@ same commits as above
</para>
<para>
- This is useful for KNN-GiST searches. HOW?
+ This is useful for KNN-GiST searches when looking for coordinates in
+ descending order.
</para>
</listitem>
--
2.14.3 (Apple Git-98)
* Re: Postgres 11 release notes
@ 2018-09-16 15:36 Bruce Momjian <bruce@momjian.us>
parent: Jonathan S. Katz <jkatz@postgresql.org>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-09-16 15:36 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, Sep 15, 2018 at 11:06:04AM -0400, Jonathan Katz wrote:
> @@ -2414,12 +2408,8 @@ same commits as above
> The option <option>--create-slot</option> creates
> the named replication slot (<option>--slot</option>)
> when the <acronym>WAL</acronym> streaming method
> - (<option>--wal-method=stream</option>) is used.
> - </para>
> -
> - <para>
> - IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
> - TEMPORARY?
> + (<option>--wal-method=stream</option>) is used. The replication slot is
> + available until it is explicitly dropped.
> </para>
> </listitem>
I have clarified the documentation for this option. This additional
release note text is not necessary.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-16 16:07 Jonathan S. Katz <jkatz@postgresql.org>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Jonathan S. Katz @ 2018-09-16 16:07 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 9/16/18 11:36 AM, Bruce Momjian wrote:
> On Sat, Sep 15, 2018 at 11:06:04AM -0400, Jonathan Katz wrote:
>> @@ -2414,12 +2408,8 @@ same commits as above
>> The option <option>--create-slot</option> creates
>> the named replication slot (<option>--slot</option>)
>> when the <acronym>WAL</acronym> streaming method
>> - (<option>--wal-method=stream</option>) is used.
>> - </para>
>> -
>> - <para>
>> - IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
>> - TEMPORARY?
>> + (<option>--wal-method=stream</option>) is used. The replication slot is
>> + available until it is explicitly dropped.
>> </para>
>> </listitem>
>
> I have clarified the documentation for this option. This additional
> release note text is not necessary.
Thanks for updating it in the docs.
I can make arguments both ways about including/not including that in the
release notes, but I've attached a patch that drops the clarification.
Thanks,
Jonathan
Attachments: download all (3 files, .tar.gz)
0001-Updates-to-major-improvements-section-of-release-not.patch (text/plain, 3.8K) download
From c0a40e7831b19f75178a45d8db00f5e91d606e33 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 10:43:44 -0400
Subject: [PATCH 1/2] Updates to major improvements section of release notes.
---
doc/src/sgml/release-11.sgml | 45 ++++++++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 684d34c091..f81dd929e3 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -6,7 +6,7 @@
<formalpara>
<title>Release date:</title>
- <para>2018-??-?? (CURRENT AS OF 2018-07-30)</para>
+ <para>2018-10-?? (CURRENT AS OF 2018-09-20)</para>
</formalpara>
<sect2>
@@ -22,7 +22,7 @@
<listitem>
<para>
- Major improvements to partitioning:
+ Improvements to partitioning functionality, including:
<itemizedlist>
<listitem>
<para>
@@ -37,9 +37,8 @@
</listitem>
<listitem>
<para>
- Improved <command>SELECT</command> query performance due to
- enhanced partition elimination during query processing and
- execution
+ Improved <command>SELECT</command> performance from enhanced partition
+ elimination strategies during query processing and execution
</para>
</listitem>
<listitem>
@@ -48,29 +47,37 @@
KEY</literal>, indexes, and triggers on partitioned tables
</para>
</listitem>
+ <listitem>
+ <para>
+ Having a "default" partition for storing data that does not match a
+ partition key
+ </para>
+ </listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
- Improvements to parallelism:
+ Improvements to parallelism, including:
<itemizedlist>
<listitem>
<para>
- Parallelized hash joins
+ B-tree indexes can now be built in parallel with
+ <command>CREATE INDEX</command>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE INDEX</command> for B-tree indexes
+ Parallelized <command>CREATE TABLE .. AS</command>,
+ <command>CREATE MATERIALIZED VIEW</command>, and certain
+ queries using <literal>UNION</literal>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE TABLE .. AS</command>,
- <command>CREATE MATERIALIZED VIEW</command>, and certain
- queries using <literal>UNION</literal>
+ Performance improvements for parallelized hash joins and parallelized
+ sequential scans
</para>
</listitem>
</itemizedlist>
@@ -79,14 +86,17 @@
<listitem>
<para>
- SQL stored procedures, with support for embedded transactions
+ SQL stored procedures that support embedded transactions. Stored
+ procedures can be created with <link linkend="sql-createprocedure">
+ <command>CREATE PROCEDURE</command></link> and executed with
+ <link linkend="sql-call"><command>CALL</command></link>
</para>
</listitem>
<listitem>
<para>
- JIT compilation of some SQL code, including support for fast evaluation
- of expressions
+ Introduction of <link linkend="jit">just-in-time</link> (JIT) compilation
+ during query execution
</para>
</listitem>
@@ -99,6 +109,13 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ Covering indexes, which can be utilized using the
+ <literal>INCLUDE</literal> clause of <command>CREATE INDEX</command>
+ </para>
+ </listitem>
+
<listitem>
<para>
Many other useful performance improvements, including making
--
2.14.3 (Apple Git-98)
0002-Remove-or-modify-placeholders-for-v11-release-notes.patch (text/plain, 2.4K) download
From 8babed4b4535bae8b46b45bec43c8117efbcb332 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 11:01:35 -0400
Subject: [PATCH 2/2] Remove or modify placeholders for v11 release notes.
---
doc/src/sgml/release-11.sgml | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index f81dd929e3..953bbd2df9 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -196,10 +196,6 @@
would be dumped without such specifications if the database locale
and encoding matched the old cluster's defaults.
</para>
-
- <para>
- DID I GET EVERYTHING?
- </para>
</listitem>
<listitem>
@@ -614,8 +610,7 @@
The new command <link linkend="sql-alterindex"><command>ALTER
INDEX ATTACH PARTITION</command></link> allows indexes to be
attached to partitions. This does not behave as a global index
- since the contents are private to each index. WARN WHEN USING
- AN EXISTING INDEX?
+ since the contents are private to each index.
</para>
</listitem>
@@ -924,7 +919,7 @@ same commits as above
</para>
<para>
- This reduces the likelihood of serialization conflicts. ACCURATE?
+ This reduces the likelihood of serialization conflicts.
</para>
</listitem>
@@ -1991,7 +1986,6 @@ same commits as above
<command>CALL</command>s or in nested PL/pgSQL DO and
<command>CALL</command> blocks that only contain other PL/pgSQL
<command>DO</command> and <command>CALL</command> blocks.
- ACCURATE?
</para>
</listitem>
@@ -2416,11 +2410,6 @@ same commits as above
when the <acronym>WAL</acronym> streaming method
(<option>--wal-method=stream</option>) is used.
</para>
-
- <para>
- IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
- TEMPORARY?
- </para>
</listitem>
<listitem>
@@ -2915,7 +2904,8 @@ same commits as above
</para>
<para>
- This is useful for KNN-GiST searches. HOW?
+ This is useful for KNN-GiST searches when looking for coordinates in
+ descending order.
</para>
</listitem>
--
2.14.3 (Apple Git-98)
* Re: Postgres 11 release notes
@ 2018-09-20 06:47 Adrien Nayrat <adrien.nayrat@anayrat.info>
parent: Peter Geoghegan <pg@bowt.ie>
0 siblings, 1 reply; 181+ messages in thread
From: Adrien Nayrat @ 2018-09-20 06:47 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 8/25/18 11:24 PM, Peter Geoghegan wrote:
> On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>> I think that's less "our" logic and more yours, that has become
>>> established because you've done most of the major release notes for a
>>> long time. I'm not trying to say that that's wrong or anything, just
>>
>> I don't do my work in a vacuum. My behavior is based on what feedback I
>> have gotten from the community on what to include/exclude.
>
> FWIW, I agree with what Andres said about planner changes and the release notes.
>
Hello,
Here is the patch that mention 1f6d515a67. Note I am not sure about my explanation.
Thanks
--
Adrien
Attachments:
release_notes.patch (text/x-patch, 559B) download
diff --combined doc/src/sgml/release-11.sgml
index 53b6fa339c,ae65431bbe..0000000000
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@@ -1056,18 -1056,6 +1056,18 @@@ same commits as abov
</listitem>
+ <listitem>
+<!--
+2017-08-21 [1f6d515a67] Push limit through subqueries to underlying sort
+-->
+
+ <para>
+ Push LIMIT through subqueries to underlying sort (if there is no filtering
+ predicate or SRF).
+ </para>
+
+ </listitem>
+
</itemizedlist>
</sect4>
* Re: Postgres 11 release notes
@ 2018-09-27 07:14 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Langote @ 2018-09-27 07:14 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; Bruce Momjian <bruce@momjian.us>; +Cc: Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
On 2018/09/17 1:07, Jonathan S. Katz wrote:
> On 9/16/18 11:36 AM, Bruce Momjian wrote:
>> On Sat, Sep 15, 2018 at 11:06:04AM -0400, Jonathan Katz wrote:
>>> @@ -2414,12 +2408,8 @@ same commits as above
>>> The option <option>--create-slot</option> creates
>>> the named replication slot (<option>--slot</option>)
>>> when the <acronym>WAL</acronym> streaming method
>>> - (<option>--wal-method=stream</option>) is used.
>>> - </para>
>>> -
>>> - <para>
>>> - IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
>>> - TEMPORARY?
>>> + (<option>--wal-method=stream</option>) is used. The replication slot is
>>> + available until it is explicitly dropped.
>>> </para>
>>> </listitem>
>>
>> I have clarified the documentation for this option. This additional
>> release note text is not necessary.
>
> Thanks for updating it in the docs.
>
> I can make arguments both ways about including/not including that in the
> release notes, but I've attached a patch that drops the clarification.
Sorry I couldn't reply sooner, but the following of your proposed text
needs to be updated a bit:
+ <listitem>
+ <para>
+ Having a "default" partition for storing data that does not match a
+ partition key
+ </para>
+ </listitem>
I think "does not match a partition key" is not accurate. Description of
default partitions further below in the release notes says this:
"The default partition can store rows that don't match any of the other
defined partitions, and is searched accordingly."
So, we could perhaps write it as:
Having a "default" partition for storing data that does not match any of
the remaining partitions
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-27 14:24 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
0 siblings, 1 reply; 181+ messages in thread
From: Alvaro Herrera @ 2018-09-27 14:24 UTC (permalink / raw)
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; Bruce Momjian <bruce@momjian.us>; Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018-Sep-27, Amit Langote wrote:
> Sorry I couldn't reply sooner, but the following of your proposed text
> needs to be updated a bit:
>
> + <listitem>
> + <para>
> + Having a "default" partition for storing data that does not match a
> + partition key
> + </para>
> + </listitem>
>
> I think "does not match a partition key" is not accurate. Description of
> default partitions further below in the release notes says this:
>
> "The default partition can store rows that don't match any of the other
> defined partitions, and is searched accordingly."
>
> So, we could perhaps write it as:
>
> Having a "default" partition for storing data that does not match any of
> the remaining partitions
Yeah, I agree that "a partition key" is not the right term to use there
(and that term is used in the press release text also). However I don't
think "remaining" is the right word there either, because it sounds as
if you're removing something.
For the Spanish translation of the press release, we ended up using the
equivalent of "for the data that does not match any other partition".
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-28 01:21 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 2 replies; 181+ messages in thread
From: Amit Langote @ 2018-09-28 01:21 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; Bruce Momjian <bruce@momjian.us>; Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 2018/09/27 23:24, Alvaro Herrera wrote:
> On 2018-Sep-27, Amit Langote wrote:
>
>> Sorry I couldn't reply sooner, but the following of your proposed text
>> needs to be updated a bit:
>>
>> + <listitem>
>> + <para>
>> + Having a "default" partition for storing data that does not match a
>> + partition key
>> + </para>
>> + </listitem>
>>
>> I think "does not match a partition key" is not accurate. Description of
>> default partitions further below in the release notes says this:
>>
>> "The default partition can store rows that don't match any of the other
>> defined partitions, and is searched accordingly."
>>
>> So, we could perhaps write it as:
>>
>> Having a "default" partition for storing data that does not match any of
>> the remaining partitions
>
> Yeah, I agree that "a partition key" is not the right term to use there
> (and that term is used in the press release text also). However I don't
> think "remaining" is the right word there either, because it sounds as
> if you're removing something.
>
> For the Spanish translation of the press release, we ended up using the
> equivalent of "for the data that does not match any other partition".
Yeah, "any other partition" is what the existing description uses too, so:
Having a "default" partition for storing data that does not match any
other partition
Thanks,
Amit
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-28 10:24 Bruce Momjian <bruce@momjian.us>
parent: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
1 sibling, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-09-28 10:24 UTC (permalink / raw)
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Jonathan S. Katz <jkatz@postgresql.org>; Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, Sep 28, 2018 at 10:21:16AM +0900, Amit Langote wrote:
> On 2018/09/27 23:24, Alvaro Herrera wrote:
> > On 2018-Sep-27, Amit Langote wrote:
> >
> >> Sorry I couldn't reply sooner, but the following of your proposed text
> >> needs to be updated a bit:
> >>
> >> + <listitem>
> >> + <para>
> >> + Having a "default" partition for storing data that does not match a
> >> + partition key
> >> + </para>
> >> + </listitem>
> >>
> >> I think "does not match a partition key" is not accurate. Description of
> >> default partitions further below in the release notes says this:
> >>
> >> "The default partition can store rows that don't match any of the other
> >> defined partitions, and is searched accordingly."
> >>
> >> So, we could perhaps write it as:
> >>
> >> Having a "default" partition for storing data that does not match any of
> >> the remaining partitions
> >
> > Yeah, I agree that "a partition key" is not the right term to use there
> > (and that term is used in the press release text also). However I don't
> > think "remaining" is the right word there either, because it sounds as
> > if you're removing something.
> >
> > For the Spanish translation of the press release, we ended up using the
> > equivalent of "for the data that does not match any other partition".
>
> Yeah, "any other partition" is what the existing description uses too, so:
>
> Having a "default" partition for storing data that does not match any
> other partition
Uh, what text are you talkinga about? I see this text in the release
notes since May:
The default partition can store rows that don't match any of the
other defined partitions, and is searched accordingly.
The press release?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-29 07:28 Amit Langote <amitlangote09@gmail.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Amit Langote @ 2018-09-29 07:28 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Alvaro Herrera <alvherre@2ndquadrant.com>; jkatz@postgresql.org, Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, Sep 28, 2018 at 7:24 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, Sep 28, 2018 at 10:21:16AM +0900, Amit Langote wrote:
> > On 2018/09/27 23:24, Alvaro Herrera wrote:
> > > On 2018-Sep-27, Amit Langote wrote:
> > >
> > >> Sorry I couldn't reply sooner, but the following of your proposed text
> > >> needs to be updated a bit:
> > >>
> > >> + <listitem>
> > >> + <para>
> > >> + Having a "default" partition for storing data that does not match a
> > >> + partition key
> > >> + </para>
> > >> + </listitem>
> > >>
> > >> I think "does not match a partition key" is not accurate. Description of
> > >> default partitions further below in the release notes says this:
> > >>
> > >> "The default partition can store rows that don't match any of the other
> > >> defined partitions, and is searched accordingly."
> > >>
> > >> So, we could perhaps write it as:
> > >>
> > >> Having a "default" partition for storing data that does not match any of
> > >> the remaining partitions
> > >
> > > Yeah, I agree that "a partition key" is not the right term to use there
> > > (and that term is used in the press release text also). However I don't
> > > think "remaining" is the right word there either, because it sounds as
> > > if you're removing something.
> > >
> > > For the Spanish translation of the press release, we ended up using the
> > > equivalent of "for the data that does not match any other partition".
> >
> > Yeah, "any other partition" is what the existing description uses too, so:
> >
> > Having a "default" partition for storing data that does not match any
> > other partition
>
> Uh, what text are you talkinga about? I see this text in the release
> notes since May:
>
> The default partition can store rows that don't match any of the
> other defined partitions, and is searched accordingly.
I was commenting on the Jonathan's patch upthread [1] whereby he
proposed to add a line about the default partition feature in the
major partitioning enhancements section at the top.
The existing text that you'd added when creating the release notes is fine.
> The press release?
Yeah, Alvaro pointed out that the press release has inaccurate text
about the default partition, but that's a separate issue, which I was
unaware of.
Thanks,
Amit
[1] https://www.postgresql.org/message-id/dcdbb9e9-cde2-fb78-fdb6-76d672d08dbc%40postgresql.org
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-09-29 14:58 Bruce Momjian <bruce@momjian.us>
parent: Amit Langote <amitlangote09@gmail.com>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-09-29 14:58 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Alvaro Herrera <alvherre@2ndquadrant.com>; jkatz@postgresql.org, Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Sat, Sep 29, 2018 at 04:28:13PM +0900, Amit Langote wrote:
> > The default partition can store rows that don't match any of the
> > other defined partitions, and is searched accordingly.
>
> I was commenting on the Jonathan's patch upthread [1] whereby he
> proposed to add a line about the default partition feature in the
> major partitioning enhancements section at the top.
>
> The existing text that you'd added when creating the release notes is fine.
>
> > The press release?
>
> Yeah, Alvaro pointed out that the press release has inaccurate text
> about the default partition, but that's a separate issue, which I was
> unaware of.
Oh, OK, thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-05 19:28 Jonathan S. Katz <jkatz@postgresql.org>
parent: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
1 sibling, 1 reply; 181+ messages in thread
From: Jonathan S. Katz @ 2018-10-05 19:28 UTC (permalink / raw)
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 9/27/18 9:21 PM, Amit Langote wrote:
> On 2018/09/27 23:24, Alvaro Herrera wrote:
>> On 2018-Sep-27, Amit Langote wrote:
>>
>>> Sorry I couldn't reply sooner, but the following of your proposed text
>>> needs to be updated a bit:
>>>
>>> + <listitem>
>>> + <para>
>>> + Having a "default" partition for storing data that does not match a
>>> + partition key
>>> + </para>
>>> + </listitem>
>>>
>>> I think "does not match a partition key" is not accurate. Description of
>>> default partitions further below in the release notes says this:
>>>
>>> "The default partition can store rows that don't match any of the other
>>> defined partitions, and is searched accordingly."
>>>
>>> So, we could perhaps write it as:
>>>
>>> Having a "default" partition for storing data that does not match any of
>>> the remaining partitions
>>
>> Yeah, I agree that "a partition key" is not the right term to use there
>> (and that term is used in the press release text also). However I don't
>> think "remaining" is the right word there either, because it sounds as
>> if you're removing something.
>>
>> For the Spanish translation of the press release, we ended up using the
>> equivalent of "for the data that does not match any other partition".
>
> Yeah, "any other partition" is what the existing description uses too, so:
>
> Having a "default" partition for storing data that does not match any
> other partition
Sorry for the slow turnaround on this. Excellent suggestion. I have
updated the patches, please see attached.
Thanks,
Jonathan
Attachments: download all (3 files, .tar.gz)
0001-Updates-to-major-improvements-section-of-release-not.patch (text/plain, 3.5K) download
From 6fee4bd74a3ce32b47a9b53ad9d5536d069b6f56 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 10:43:44 -0400
Subject: [PATCH 1/2] Updates to major improvements section of release notes.
---
doc/src/sgml/release-11.sgml | 41 +++++++++++++++++++++++++++++------------
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index ae65431bbe..f9d93b734e 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -6,7 +6,7 @@
<formalpara>
<title>Release date:</title>
- <para>2018-??-?? (CURRENT AS OF 2018-07-30)</para>
+ <para>2018-10-?? (CURRENT AS OF 2018-09-20)</para>
</formalpara>
<sect2>
@@ -22,7 +22,7 @@
<listitem>
<para>
- Major improvements to partitioning:
+ Improvements to partitioning functionality, including:
<itemizedlist>
<listitem>
<para>
@@ -37,9 +37,8 @@
</listitem>
<listitem>
<para>
- Improved <command>SELECT</command> query performance due to
- enhanced partition elimination during query processing and
- execution
+ Improved <command>SELECT</command> performance from enhanced partition
+ elimination strategies during query processing and execution
</para>
</listitem>
<listitem>
@@ -48,29 +47,37 @@
KEY</literal>, indexes, and triggers on partitioned tables
</para>
</listitem>
+ <listitem>
+ <para>
+ Having a "default" partition for storing data that does not match any
+ of the remaining partitions
+ </para>
+ </listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
- Improvements to parallelism:
+ Improvements to parallelism, including:
<itemizedlist>
<listitem>
<para>
- Parallelized hash joins
+ B-tree indexes can now be built in parallel with
+ <command>CREATE INDEX</command>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE INDEX</command> for B-tree indexes
+ Parallelized <command>CREATE TABLE .. AS</command>,
+ <command>CREATE MATERIALIZED VIEW</command>, and certain
+ queries using <literal>UNION</literal>
</para>
</listitem>
<listitem>
<para>
- Parallelized <command>CREATE TABLE .. AS</command>,
- <command>CREATE MATERIALIZED VIEW</command>, and certain
- queries using <literal>UNION</literal>
+ Performance improvements for parallelized hash joins and parallelized
+ sequential scans
</para>
</listitem>
</itemizedlist>
@@ -79,7 +86,10 @@
<listitem>
<para>
- SQL stored procedures, with support for embedded transactions
+ SQL stored procedures that support embedded transactions. Stored
+ procedures can be created with <link linkend="sql-createprocedure">
+ <command>CREATE PROCEDURE</command></link> and executed with
+ <link linkend="sql-call"><command>CALL</command></link>
</para>
</listitem>
@@ -99,6 +109,13 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ Covering indexes, which can be utilized using the
+ <literal>INCLUDE</literal> clause of <command>CREATE INDEX</command>
+ </para>
+ </listitem>
+
<listitem>
<para>
Many other useful performance improvements, including making
--
2.14.3 (Apple Git-98)
0002-Remove-or-modify-placeholders-for-v11-release-notes.patch (text/plain, 2.4K) download
From a1922a4a590655ac9544fd41460a998fd975523b Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Sat, 15 Sep 2018 11:01:35 -0400
Subject: [PATCH 2/2] Remove or modify placeholders for v11 release notes.
---
doc/src/sgml/release-11.sgml | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index f9d93b734e..ca42f28cc9 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -196,10 +196,6 @@
would be dumped without such specifications if the database locale
and encoding matched the old cluster's defaults.
</para>
-
- <para>
- DID I GET EVERYTHING?
- </para>
</listitem>
<listitem>
@@ -614,8 +610,7 @@
The new command <link linkend="sql-alterindex"><command>ALTER
INDEX ATTACH PARTITION</command></link> allows indexes to be
attached to partitions. This does not behave as a global index
- since the contents are private to each index. WARN WHEN USING
- AN EXISTING INDEX?
+ since the contents are private to each index.
</para>
</listitem>
@@ -924,7 +919,7 @@ same commits as above
</para>
<para>
- This reduces the likelihood of serialization conflicts. ACCURATE?
+ This reduces the likelihood of serialization conflicts.
</para>
</listitem>
@@ -1997,7 +1992,6 @@ same commits as above
<command>CALL</command>s or in nested PL/pgSQL DO and
<command>CALL</command> blocks that only contain other PL/pgSQL
<command>DO</command> and <command>CALL</command> blocks.
- ACCURATE?
</para>
</listitem>
@@ -2422,11 +2416,6 @@ same commits as above
when the <acronym>WAL</acronym> streaming method
(<option>--wal-method=stream</option>) is used.
</para>
-
- <para>
- IS IT CLEAR FROM THE DOCS THAT THE REPLICATION SLOT IS NOT
- TEMPORARY?
- </para>
</listitem>
<listitem>
@@ -2921,7 +2910,8 @@ same commits as above
</para>
<para>
- This is useful for KNN-GiST searches. HOW?
+ This is useful for KNN-GiST searches when looking for coordinates in
+ descending order.
</para>
</listitem>
--
2.14.3 (Apple Git-98)
* Re: Postgres 11 release notes
@ 2018-10-05 21:22 Bruce Momjian <bruce@momjian.us>
parent: Jonathan S. Katz <jkatz@postgresql.org>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-10-05 21:22 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Alvaro Herrera <alvherre@2ndquadrant.com>; Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Fri, Oct 5, 2018 at 03:28:41PM -0400, Jonathan Katz wrote:
> On 9/27/18 9:21 PM, Amit Langote wrote:
> > Yeah, "any other partition" is what the existing description uses too, so:
> >
> > Having a "default" partition for storing data that does not match any
> > other partition
>
> Sorry for the slow turnaround on this. Excellent suggestion. I have
> updated the patches, please see attached.
Patch applied:
https://git.postgresql.org/pg/commitdiff/6eb612fea9d080f2ae77ecb7091e73dc9f298c97
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-05 21:24 Jonathan S. Katz <jkatz@postgresql.org>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Jonathan S. Katz @ 2018-10-05 21:24 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>; Alvaro Herrera <alvherre@2ndquadrant.com>; Michael Banck <michael.banck@credativ.de>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 10/5/18 5:22 PM, Bruce Momjian wrote:
> On Fri, Oct 5, 2018 at 03:28:41PM -0400, Jonathan Katz wrote:
>> On 9/27/18 9:21 PM, Amit Langote wrote:
>>> Yeah, "any other partition" is what the existing description uses too, so:
>>>
>>> Having a "default" partition for storing data that does not match any
>>> other partition
>>
>> Sorry for the slow turnaround on this. Excellent suggestion. I have
>> updated the patches, please see attached.
>
> Patch applied:
>
> https://git.postgresql.org/pg/commitdiff/6eb612fea9d080f2ae77ecb7091e73dc9f298c97
>
Thank you!
Jonathan
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-08 10:05 Adrien NAYRAT <adrien.nayrat@anayrat.info>
parent: Adrien Nayrat <adrien.nayrat@anayrat.info>
0 siblings, 1 reply; 181+ messages in thread
From: Adrien NAYRAT @ 2018-10-08 10:05 UTC (permalink / raw)
To: Peter Geoghegan <pg@bowt.ie>; Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/20/18 8:47 AM, Adrien Nayrat wrote:
> On 8/25/18 11:24 PM, Peter Geoghegan wrote:
>> On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>>> I think that's less "our" logic and more yours, that has become
>>>> established because you've done most of the major release notes for a
>>>> long time. I'm not trying to say that that's wrong or anything, just
>>>
>>> I don't do my work in a vacuum. My behavior is based on what feedback I
>>> have gotten from the community on what to include/exclude.
>>
>> FWIW, I agree with what Andres said about planner changes and the release notes.
>>
>
> Hello,
>
> Here is the patch that mention 1f6d515a67. Note I am not sure about my explanation.
>
>
> Thanks
>
Hi,
It seems this change has not been added to release notes? Should I
change something in my path?
Thanks,
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-08 15:20 Bruce Momjian <bruce@momjian.us>
parent: Adrien NAYRAT <adrien.nayrat@anayrat.info>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-10-08 15:20 UTC (permalink / raw)
To: Adrien NAYRAT <adrien.nayrat@anayrat.info>; +Cc: Peter Geoghegan <pg@bowt.ie>; Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Mon, Oct 8, 2018 at 12:05:03PM +0200, Adrien NAYRAT wrote:
> On 9/20/18 8:47 AM, Adrien Nayrat wrote:
> >On 8/25/18 11:24 PM, Peter Geoghegan wrote:
> >>On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >>>>I think that's less "our" logic and more yours, that has become
> >>>>established because you've done most of the major release notes for a
> >>>>long time. I'm not trying to say that that's wrong or anything, just
> >>>
> >>>I don't do my work in a vacuum. My behavior is based on what feedback I
> >>>have gotten from the community on what to include/exclude.
> >>
> >>FWIW, I agree with what Andres said about planner changes and the release notes.
> >>
> >
> >Hello,
> >
> >Here is the patch that mention 1f6d515a67. Note I am not sure about my explanation.
> >
> >
> >Thanks
> >
>
> Hi,
>
> It seems this change has not been added to release notes? Should I change
> something in my path?
Uh, where are you looking? We don't rebuild the beta docs until the
next beta release, but you can see the changes in the developer docs:
https://www.postgresql.org/docs/devel/static/release-11.html
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-08 15:44 Adrien NAYRAT <adrien.nayrat@anayrat.info>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Adrien NAYRAT @ 2018-10-08 15:44 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Peter Geoghegan <pg@bowt.ie>; Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 10/8/18 5:20 PM, Bruce Momjian wrote:
> Uh, where are you looking? We don't rebuild the beta docs until the
> next beta release, but you can see the changes in the developer docs:
>
> https://www.postgresql.org/docs/devel/static/release-11.html
I looked in doc/src/sgml/release-11.sgml
And even on https://www.postgresql.org/docs/devel/static/release-11.html
I don't see mention of 1f6d515a67
Thanks
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-09 01:28 Bruce Momjian <bruce@momjian.us>
parent: Adrien NAYRAT <adrien.nayrat@anayrat.info>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-10-09 01:28 UTC (permalink / raw)
To: Adrien NAYRAT <adrien.nayrat@anayrat.info>; +Cc: Peter Geoghegan <pg@bowt.ie>; Andres Freund <andres@anarazel.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Mon, Oct 8, 2018 at 05:44:32PM +0200, Adrien NAYRAT wrote:
> On 10/8/18 5:20 PM, Bruce Momjian wrote:
> >Uh, where are you looking? We don't rebuild the beta docs until the
> >next beta release, but you can see the changes in the developer docs:
> >
> > https://www.postgresql.org/docs/devel/static/release-11.html
>
> I looked in doc/src/sgml/release-11.sgml
>
> And even on https://www.postgresql.org/docs/devel/static/release-11.html I
> don't see mention of 1f6d515a67
I did not think there was sufficient interest in adding this item. If
we add it we need to discuss adding all similar items.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-10 19:55 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Andres Freund @ 2018-10-10 19:55 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Adrien NAYRAT <adrien.nayrat@anayrat.info>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
On 2018-10-08 21:28:02 -0400, Bruce Momjian wrote:
> On Mon, Oct 8, 2018 at 05:44:32PM +0200, Adrien NAYRAT wrote:
> > On 10/8/18 5:20 PM, Bruce Momjian wrote:
> > >Uh, where are you looking? We don't rebuild the beta docs until the
> > >next beta release, but you can see the changes in the developer docs:
> > >
> > > https://www.postgresql.org/docs/devel/static/release-11.html
> >
> > I looked in doc/src/sgml/release-11.sgml
> >
> > And even on https://www.postgresql.org/docs/devel/static/release-11.html I
> > don't see mention of 1f6d515a67
>
> I did not think there was sufficient interest in adding this item. If
> we add it we need to discuss adding all similar items.
Several people argued for introducing it, you're the only one that was
against it. Adrien, Amit Kapila, Peter Geoghegan, and I all said we
think that kind of thing should be included.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-10 22:06 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-10-10 22:06 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Adrien NAYRAT <adrien.nayrat@anayrat.info>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Oct 10, 2018 at 12:55:33PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-10-08 21:28:02 -0400, Bruce Momjian wrote:
> > On Mon, Oct 8, 2018 at 05:44:32PM +0200, Adrien NAYRAT wrote:
> > > On 10/8/18 5:20 PM, Bruce Momjian wrote:
> > > >Uh, where are you looking? We don't rebuild the beta docs until the
> > > >next beta release, but you can see the changes in the developer docs:
> > > >
> > > > https://www.postgresql.org/docs/devel/static/release-11.html
> > >
> > > I looked in doc/src/sgml/release-11.sgml
> > >
> > > And even on https://www.postgresql.org/docs/devel/static/release-11.html I
> > > don't see mention of 1f6d515a67
> >
> > I did not think there was sufficient interest in adding this item. If
> > we add it we need to discuss adding all similar items.
>
> Several people argued for introducing it, you're the only one that was
> against it. Adrien, Amit Kapila, Peter Geoghegan, and I all said we
> think that kind of thing should be included.
Then you need to start a new thread and argue that we need to include
more optimizer items in the release notes. My point was that I was
using the existing criteria, and if we want to change it, we have to do
it consistently, not just jam in one item.
Once we agree we can go back and see what we missed in PG 11.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-10 22:13 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 181+ messages in thread
From: Bruce Momjian @ 2018-10-10 22:13 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Adrien NAYRAT <adrien.nayrat@anayrat.info>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Oct 10, 2018 at 06:06:01PM -0400, Bruce Momjian wrote:
> On Wed, Oct 10, 2018 at 12:55:33PM -0700, Andres Freund wrote:
> > Several people argued for introducing it, you're the only one that was
> > against it. Adrien, Amit Kapila, Peter Geoghegan, and I all said we
> > think that kind of thing should be included.
>
> Then you need to start a new thread and argue that we need to include
> more optimizer items in the release notes. My point was that I was
> using the existing criteria, and if we want to change it, we have to do
> it consistently, not just jam in one item.
>
> Once we agree we can go back and see what we missed in PG 11.
Years ago someone said they wanted more optimizer items in the release
notes, so I did it, and then many more people said they didn't want it
--- I don't want to repeat the experience.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
* Re: Postgres 11 release notes
@ 2018-10-10 23:57 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 181+ messages in thread
From: Bruce Momjian @ 2018-10-10 23:57 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Adrien NAYRAT <adrien.nayrat@anayrat.info>; Peter Geoghegan <pg@bowt.ie>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Oct 10, 2018 at 06:13:56PM -0400, Bruce Momjian wrote:
> On Wed, Oct 10, 2018 at 06:06:01PM -0400, Bruce Momjian wrote:
> > On Wed, Oct 10, 2018 at 12:55:33PM -0700, Andres Freund wrote:
> > > Several people argued for introducing it, you're the only one that was
> > > against it. Adrien, Amit Kapila, Peter Geoghegan, and I all said we
> > > think that kind of thing should be included.
> >
> > Then you need to start a new thread and argue that we need to include
> > more optimizer items in the release notes. My point was that I was
> > using the existing criteria, and if we want to change it, we have to do
> > it consistently, not just jam in one item.
> >
> > Once we agree we can go back and see what we missed in PG 11.
>
> Years ago someone said they wanted more optimizer items in the release
> notes, so I did it, and then many more people said they didn't want it
> --- I don't want to repeat the experience.
Thinking some more, if this is this _only_ optimizer improvement you
think I missed, let's just add it and call it done, and we will not
re-litigate the criteria used for the release notes.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 181+ messages in thread
end of thread, other threads:[~2018-10-10 23:57 UTC | newest]
Thread overview: 181+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-05-11 15:08 Postgres 11 release notes Bruce Momjian <bruce@momjian.us>
2018-05-11 16:29 ` Fabien COELHO <coelho@cri.ensmp.fr>
2018-05-11 18:01 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 16:49 ` Teodor Sigaev <teodor@sigaev.ru>
2018-05-11 18:44 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 18:50 ` Andres Freund <andres@anarazel.de>
2018-05-11 18:59 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 19:00 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2018-05-11 19:11 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 19:22 ` Andres Freund <andres@anarazel.de>
2018-05-11 19:26 ` Justin Pryzby <pryzby@telsasoft.com>
2018-05-11 19:04 ` Andres Freund <andres@anarazel.de>
2018-05-11 19:17 ` Peter Geoghegan <pg@bowt.ie>
2018-05-11 19:28 ` Peter Geoghegan <pg@bowt.ie>
2018-05-11 21:04 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 21:03 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 19:20 ` Teodor Sigaev <teodor@sigaev.ru>
2018-05-11 21:06 ` Bruce Momjian <bruce@momjian.us>
2018-05-12 20:22 ` Peter Geoghegan <pg@bowt.ie>
2018-05-13 00:47 ` Bruce Momjian <bruce@momjian.us>
2018-05-14 11:47 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-05-14 20:37 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 17:40 ` Chapman Flack <chap@anastigmatix.net>
2018-05-11 18:50 ` Bruce Momjian <bruce@momjian.us>
2018-05-11 18:59 ` Andres Freund <andres@anarazel.de>
2018-05-11 19:02 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2018-05-11 19:14 ` Bruce Momjian <bruce@momjian.us>
2018-05-13 06:43 ` Michael Paquier <michael@paquier.xyz>
2018-05-14 00:26 ` Michael Paquier <michael@paquier.xyz>
2018-05-14 11:10 ` David Steele <david@pgmasters.net>
2018-05-14 20:10 ` Bruce Momjian <bruce@momjian.us>
2018-05-14 20:08 ` Bruce Momjian <bruce@momjian.us>
2018-05-14 20:04 ` Bruce Momjian <bruce@momjian.us>
2018-05-14 23:10 ` Michael Paquier <michael@paquier.xyz>
2018-05-15 00:45 ` Bruce Momjian <bruce@momjian.us>
2018-05-16 04:22 ` Michael Paquier <michael@paquier.xyz>
2018-05-16 10:09 ` Heikki Linnakangas <hlinnaka@iki.fi>
2018-05-16 11:59 ` Michael Paquier <michael@paquier.xyz>
2018-05-17 00:20 ` Bruce Momjian <bruce@momjian.us>
2018-05-17 00:56 ` Michael Paquier <michael@paquier.xyz>
2018-05-17 01:09 ` Bruce Momjian <bruce@momjian.us>
2018-05-17 12:48 ` Michael Paquier <michael@paquier.xyz>
2018-05-17 13:56 ` Bruce Momjian <bruce@momjian.us>
2018-05-17 13:55 ` Bruce Momjian <bruce@momjian.us>
2018-05-17 13:38 ` Magnus Hagander <magnus@hagander.net>
2018-05-17 00:13 ` Bruce Momjian <bruce@momjian.us>
2018-05-13 08:43 ` Đặng Minh Hướng <kakalot49@gmail.com>
2018-05-14 20:28 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 03:12 ` Dang Minh Huong <kakalot49@gmail.com>
2018-05-15 06:00 ` David Rowley <david.rowley@2ndquadrant.com>
2018-05-15 06:40 ` Huong Dangminh <huo-dangminh@ys.jp.nec.com>
2018-05-15 19:44 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 14:01 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-05-15 19:04 ` David Rowley <david.rowley@2ndquadrant.com>
2018-05-13 09:53 ` Amit Langote <amitlangote09@gmail.com>
2018-05-14 20:30 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 03:46 ` Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
2018-05-18 15:58 ` Amit Langote <amitlangote09@gmail.com>
2018-05-21 07:34 ` David Rowley <david.rowley@2ndquadrant.com>
2018-05-21 08:28 ` Haribabu Kommi <kommi.haribabu@gmail.com>
2018-05-23 01:34 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 01:55 ` Haribabu Kommi <kommi.haribabu@gmail.com>
2018-05-23 02:40 ` Bruce Momjian <bruce@momjian.us>
2018-05-21 14:58 ` Amit Langote <amitlangote09@gmail.com>
2018-05-23 01:18 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 02:06 ` David Rowley <david.rowley@2ndquadrant.com>
2018-05-23 02:41 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 01:16 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 01:28 ` Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
2018-05-23 01:36 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 01:54 ` Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
2018-05-13 11:10 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-13 11:25 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-14 20:36 ` Bruce Momjian <bruce@momjian.us>
2018-05-14 20:35 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 03:15 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-15 18:47 ` Bruce Momjian <bruce@momjian.us>
2018-05-16 04:25 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-17 00:24 ` Bruce Momjian <bruce@momjian.us>
2018-05-17 02:27 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-14 12:04 ` Dilip Kumar <dilipbalaut@gmail.com>
2018-05-14 20:41 ` Bruce Momjian <bruce@momjian.us>
2018-05-18 10:28 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-15 00:19 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-15 00:46 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 00:51 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-15 19:37 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 21:11 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-15 23:12 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 23:31 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-15 05:26 ` Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
2018-05-15 19:45 ` Bruce Momjian <bruce@momjian.us>
2018-05-16 09:30 ` Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
2018-05-15 06:13 ` David Rowley <david.rowley@2ndquadrant.com>
2018-05-15 07:34 ` Amit Kapila <amit.kapila16@gmail.com>
2018-05-15 19:55 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 23:33 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-15 23:37 ` Bruce Momjian <bruce@momjian.us>
2018-05-15 23:52 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-15 23:57 ` Bruce Momjian <bruce@momjian.us>
2018-05-16 00:01 ` Tatsuo Ishii <ishii@sraoss.co.jp>
2018-05-16 00:03 ` Bruce Momjian <bruce@momjian.us>
2018-05-16 14:08 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2018-05-16 16:23 ` Magnus Hagander <magnus@hagander.net>
2018-05-16 16:24 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2018-05-16 16:28 ` Magnus Hagander <magnus@hagander.net>
2018-05-17 00:29 ` Bruce Momjian <bruce@momjian.us>
2018-05-16 10:50 ` Heikki Linnakangas <hlinnaka@iki.fi>
2018-05-17 00:26 ` Bruce Momjian <bruce@momjian.us>
2018-05-17 13:35 ` Michael Paquier <michael@paquier.xyz>
2018-05-17 18:23 ` Bruce Momjian <bruce@momjian.us>
2018-05-18 01:19 ` Michael Paquier <michael@paquier.xyz>
2018-05-18 05:56 ` Andrey Borodin <x4mmm@yandex-team.ru>
2018-05-18 13:53 ` Bruce Momjian <bruce@momjian.us>
2018-05-18 14:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-05-23 01:02 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 03:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-05-24 02:06 ` Bruce Momjian <bruce@momjian.us>
2018-05-23 01:37 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-05-23 01:42 ` Bruce Momjian <bruce@momjian.us>
2018-06-16 12:56 ` Darafei "Komяpa" Praliaskouski <me@komzpa.net>
2018-06-19 09:15 ` Alexander Korotkov <a.korotkov@postgrespro.ru>
2018-06-19 10:40 ` Alexander Korotkov <a.korotkov@postgrespro.ru>
2018-06-19 15:18 ` Daniel Gustafsson <daniel@yesql.se>
2018-06-19 15:37 ` Alexander Korotkov <a.korotkov@postgrespro.ru>
2018-06-21 12:56 ` Alexander Korotkov <a.korotkov@postgrespro.ru>
2018-06-30 18:11 ` Brad DeJong <bpd0018@gmail.com>
2018-06-30 18:48 ` Daniel Gustafsson <daniel@yesql.se>
2018-06-30 18:56 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-06-30 21:48 ` Yaroslav <ladayaroslav@yandex.ru>
2018-06-30 21:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-07-01 19:57 ` Jonathan S. Katz <jonathan.katz@excoventures.com>
2018-07-12 15:14 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-10 05:06 ` Masahiko Sawada <sawada.mshk@gmail.com>
2018-08-10 10:10 ` Alexander Korotkov <a.korotkov@postgrespro.ru>
2018-08-13 00:10 ` Masahiko Sawada <sawada.mshk@gmail.com>
2018-05-18 15:56 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-05-21 16:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-05-21 16:52 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-05-22 02:36 ` Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>
2018-06-09 20:35 ` David G. Johnston <david.g.johnston@gmail.com>
2018-06-09 20:58 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-06-09 23:20 ` Justin Pryzby <pryzby@telsasoft.com>
2018-07-09 05:18 ` Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
2018-07-09 05:28 ` Andres Freund <andres@anarazel.de>
2018-07-09 14:36 ` Bruce Momjian <bruce@momjian.us>
2018-07-09 14:52 ` David Fetter <david@fetter.org>
2018-07-10 01:09 ` Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
2018-07-10 01:17 ` Andres Freund <andres@anarazel.de>
2018-08-12 09:21 ` Adrien Nayrat <adrien.nayrat@anayrat.info>
2018-08-25 18:41 ` Bruce Momjian <bruce@momjian.us>
2018-08-25 18:42 ` Andres Freund <andres@anarazel.de>
2018-08-25 18:47 ` Bruce Momjian <bruce@momjian.us>
2018-08-25 19:17 ` Andres Freund <andres@anarazel.de>
2018-08-25 21:18 ` Bruce Momjian <bruce@momjian.us>
2018-08-25 21:24 ` Peter Geoghegan <pg@bowt.ie>
2018-09-20 06:47 ` Adrien Nayrat <adrien.nayrat@anayrat.info>
2018-10-08 10:05 ` Adrien NAYRAT <adrien.nayrat@anayrat.info>
2018-10-08 15:20 ` Bruce Momjian <bruce@momjian.us>
2018-10-08 15:44 ` Adrien NAYRAT <adrien.nayrat@anayrat.info>
2018-10-09 01:28 ` Bruce Momjian <bruce@momjian.us>
2018-10-10 19:55 ` Andres Freund <andres@anarazel.de>
2018-10-10 22:06 ` Bruce Momjian <bruce@momjian.us>
2018-10-10 22:13 ` Bruce Momjian <bruce@momjian.us>
2018-10-10 23:57 ` Bruce Momjian <bruce@momjian.us>
2018-08-26 11:23 ` Amit Kapila <amit.kapila16@gmail.com>
2018-09-12 17:34 ` Michael Banck <michael.banck@credativ.de>
2018-09-15 15:06 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-09-16 15:14 ` Bruce Momjian <bruce@momjian.us>
2018-09-16 15:17 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-09-16 15:36 ` Bruce Momjian <bruce@momjian.us>
2018-09-16 16:07 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-09-27 07:14 ` Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
2018-09-27 14:24 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2018-09-28 01:21 ` Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
2018-09-28 10:24 ` Bruce Momjian <bruce@momjian.us>
2018-09-29 07:28 ` Amit Langote <amitlangote09@gmail.com>
2018-09-29 14:58 ` Bruce Momjian <bruce@momjian.us>
2018-10-05 19:28 ` Jonathan S. Katz <jkatz@postgresql.org>
2018-10-05 21:22 ` Bruce Momjian <bruce@momjian.us>
2018-10-05 21:24 ` Jonathan S. Katz <jkatz@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox