Thread: PG 13 release notes, first draft

PG 13 release notes, first draft

From
Bruce Momjian
Date:
I have committed the first draft of the PG 13 release notes.  You can
see them here:

    https://momjian.us/pgsql_docs/release-13.html

It still needs markup, word wrap, and indenting.  The community doc
build should happen in a few hours.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
David Rowley
Date:
On Tue, 5 May 2020 at 15:16, Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thanks a lot for putting that together.

In previous years, during the development of this you've had HTML
comments to include the commit details.  Are you going to do that this
year? or did they just disappear in some compilation phase you've
done?

David



Re: PG 13 release notes, first draft

From
David Rowley
Date:
On Tue, 5 May 2020 at 16:10, David Rowley <dgrowleyml@gmail.com> wrote:
> In previous years, during the development of this you've had HTML
> comments to include the commit details.  Are you going to do that this
> year? or did they just disappear in some compilation phase you've
> done?

Never mind. I just saw them all in the commit you've pushed.

David



Re: PG 13 release notes, first draft

From
Thomas Munro
Date:
On Tue, May 5, 2020 at 3:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Hi Bruce,

Thanks!  Some feedback:

+2020-04-08 [3985b600f] Support PrefetchBuffer() in recovery.
+-->
+
+<para>
+Speedup recovery by prefetching pages (Thomas Munro)

Unfortunately that commit was just an infrastructural change to allow
the PrefetchBuffer() function to work in recovery, but the main
"prefetching during recovery" patch to actually make use of it to go
faster didn't make it.  So this item shouldn't be in the release
notes.

+2020-04-07 [4c04be9b0] Introduce xid8-based functions to replace txid_XXX.
+-->
+
+<para>
+Update all transaction id functions to support xid8 (Thomas Munro)
+</para>
+
+<para>
+They use the same names as the xid data type versions.
+</para>

The names are actually different.  How about: "New xid8-based
functions replace the txid family of functions, but the older names
are still supported for backward compatibility."

+2019-10-16 [d5ac14f9c] Use libc version as a collation version on glibc systems
+-->
+
+<para>
+Use the glibc version as the collation version (Thomas Munro)
+</para>
+
+<para>
+If the glibc version changes, a warning will be issued when a
mismatching collation is used.
+</para>

I would add a qualifier "in some cases", since it doesn't work for
default collations yet.  (That'll now have to wait for 14).



Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Bruce,

> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>     https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thanks for working on this.

* Add CREATE DATABASE LOCALE option (Fabien COELHO)
* Add function gen_random_uuid to generate version 4 UUIDs (Fabien COELHO)

I'm not responsible for these, I just reviewed them. ISTM that the author 
for both is the committer, Peter Eisentraut.

Maybe there is something amiss in the commit-log-to-release-notes script?
My name clearly appears after "reviewed by:?"

* "DOCUMENT THE DEFAULT GENERATION METHOD"
   => The default is still to generate data client-side.

I do not see a "documentation" section, whereas there has been significant 
doc changes, such as function table layouts (Tom), glossary (Corey, 
Jürgen, Roger, Alvarro), binary/text string functions (Karl) and possibly 
others. Having a good documentation contributes to making postgres a very 
good tool, improving it is is not very glamorous, ISTM that such 
contributions should not be overlooked.

-- 
Fabien.

Re: PG 13 release notes, first draft

From
Pavel Stehule
Date:
Hi

út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
I have committed the first draft of the PG 13 release notes.  You can
see them here:

        https://momjian.us/pgsql_docs/release-13.html

It still needs markup, word wrap, and indenting.  The community doc
build should happen in a few hours.

There is not note about new polymorphic type "anycompatible"

 

--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Re: PG 13 release notes, first draft

From
Julien Rouhaud
Date:
Hi,

On Tue, May 5, 2020 at 7:47 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Hi
>
> út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
>>
>> I have committed the first draft of the PG 13 release notes.  You can
>> see them here:
>>
>>         https://momjian.us/pgsql_docs/release-13.html
>>
>> It still needs markup, word wrap, and indenting.  The community doc
>> build should happen in a few hours.
>
>
> There is not note about new polymorphic type "anycompatible"
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=24e2885ee304cb6a94fdfc25a1a108344ed9f4f7

There's also no note about avoiding full GIN index scan
(https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4b754d6c16e16cc1a1adf12ab0f48603069a0efd).
That's a corner case optimization but it can be a huge improvement
when you hit the problem.



Re: PG 13 release notes, first draft

From
Juan José Santamaría Flecha
Date:

On Tue, May 5, 2020 at 5:16 AM Bruce Momjian <bruce@momjian.us> wrote:
I have committed the first draft of the PG 13 release notes.  You can
see them here:

        https://momjian.us/pgsql_docs/release-13.html

It still needs markup, word wrap, and indenting.  The community doc
build should happen in a few hours.
 
There is one entry "Add support for collation versions on Windows" where I am quoted as author. Actually, I was a reviewer, the author is Thomas Munro.

Also, I am credited as sole author of "Allow to_date/to_timestamp to recognize non-English month/day names", when the case is that Tom Lane did more than a few cosmetics changes when committing and I think he should be quoted as co-author (if he agrees).

Regards,

Juan José Santamaría Flecha
 

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May  4, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
> 
>     https://momjian.us/pgsql_docs/release-13.html
> 
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

I wanted to point out there are 180 changes listed in the release notes,
which very closely matches the count of previous major releases.  I
don't think there are as many major _features_ in this release as
previous ones.

Also, I see little to no progress on these features in PG 13:

*  online checksum changes
*  zheap
*  sharding

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
John Naylor
Date:
Hi Bruce, thanks for working on this again!

+<para>
+Allow UTF-8 escapes, e.g., E'\u####', in clients that don't use UTF-8
encoding (Tom Lane)
+</para>

I believe the term we want here is "Unicode escapes". This patch is
about the server encoding, which formerly needed to be utf-8 for
non-ascii characters. (I think the client encoding doesn't matter as
long as ascii bytes are represented.)

+<para>
+The UTF-8 characters must be available in the server encoding.
+</para>

Same here, s/UTF-8/Unicode/.

-- 
John Naylor                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> > 
> >     https://momjian.us/pgsql_docs/release-13.html
> > 
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Thanks for working on this.
> 
> * Add CREATE DATABASE LOCALE option (Fabien COELHO)
> * Add function gen_random_uuid to generate version 4 UUIDs (Fabien COELHO)
> 
> I'm not responsible for these, I just reviewed them. ISTM that the author
> for both is the committer, Peter Eisentraut.
> 
> Maybe there is something amiss in the commit-log-to-release-notes script?
> My name clearly appears after "reviewed by:?"

Sorry, those were all my mistaken reading of the commit message.

> 
> * "DOCUMENT THE DEFAULT GENERATION METHOD"
>   => The default is still to generate data client-side.

My point is that the docs are not clear about this.  Can you fix it?

> I do not see a "documentation" section, whereas there has been significant
> doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen,

I did list the glossary.

> Roger, Alvarro), binary/text string functions (Karl) and possibly others.

I wasn't sure documentation _layout_ changes should be listed.

> Having a good documentation contributes to making postgres a very good tool,
> improving it is is not very glamorous, ISTM that such contributions should
> not be overlooked.

Yes, I would be good to know from others if that kind of stuff should
be included.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 04:14:42PM +1200, Thomas Munro wrote:
> On Tue, May 5, 2020 at 3:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Hi Bruce,
> 
> Thanks!  Some feedback:
> 
> +2020-04-08 [3985b600f] Support PrefetchBuffer() in recovery.
> +-->
> +
> +<para>
> +Speedup recovery by prefetching pages (Thomas Munro)
> 
> Unfortunately that commit was just an infrastructural change to allow
> the PrefetchBuffer() function to work in recovery, but the main
> "prefetching during recovery" patch to actually make use of it to go
> faster didn't make it.  So this item shouldn't be in the release
> notes.

Agreed, removed.

> +2020-04-07 [4c04be9b0] Introduce xid8-based functions to replace txid_XXX.
> +-->
> +
> +<para>
> +Update all transaction id functions to support xid8 (Thomas Munro)
> +</para>
> +
> +<para>
> +They use the same names as the xid data type versions.
> +</para>
> 
> The names are actually different.  How about: "New xid8-based
> functions replace the txid family of functions, but the older names
> are still supported for backward compatibility."

Agreed.

> +2019-10-16 [d5ac14f9c] Use libc version as a collation version on glibc systems
> +-->
> +
> +<para>
> +Use the glibc version as the collation version (Thomas Munro)
> +</para>
> +
> +<para>
> +If the glibc version changes, a warning will be issued when a
> mismatching collation is used.
> +</para>
> 
> I would add a qualifier "in some cases", since it doesn't work for
> default collations yet.  (That'll now have to wait for 14).

Done.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 07:46:34AM +0200, Pavel Stehule wrote:
> Hi
> 
> út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
> 
>     I have committed the first draft of the PG 13 release notes.  You can
>     see them here:
> 
>             https://momjian.us/pgsql_docs/release-13.html
> 
>     It still needs markup, word wrap, and indenting.  The community doc
>     build should happen in a few hours.
> 
> 
> There is not note about new polymorphic type "anycompatible"
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
> 24e2885ee304cb6a94fdfc25a1a108344ed9f4f7

Sorry I missed that.  Must have thought it was non-visible work that was
part of another features.  Here is the new text:

    Add polymorphic data types for use by functions requiring
    compatible arguments (Pavel Stehule)

    The new data types are anycompatible, anycompatiblearray,
    anycompatiblenonarray, and anycompatiblerange.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Pavel Stehule
Date:


út 5. 5. 2020 v 16:18 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
On Tue, May  5, 2020 at 07:46:34AM +0200, Pavel Stehule wrote:
> Hi
>
> út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
>
>     I have committed the first draft of the PG 13 release notes.  You can
>     see them here:
>
>             https://momjian.us/pgsql_docs/release-13.html
>
>     It still needs markup, word wrap, and indenting.  The community doc
>     build should happen in a few hours.
>
>
> There is not note about new polymorphic type "anycompatible"
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
> 24e2885ee304cb6a94fdfc25a1a108344ed9f4f7

Sorry I missed that.  Must have thought it was non-visible work that was
part of another features.  Here is the new text:

        Add polymorphic data types for use by functions requiring
        compatible arguments (Pavel Stehule)

        The new data types are anycompatible, anycompatiblearray,
        anycompatiblenonarray, and anycompatiblerange.

no problem, thank you

Pavel


--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 08:10:54AM +0200, Julien Rouhaud wrote:
> Hi,
> 
> On Tue, May 5, 2020 at 7:47 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >
> > Hi
> >
> > út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
> >>
> >> I have committed the first draft of the PG 13 release notes.  You can
> >> see them here:
> >>
> >>         https://momjian.us/pgsql_docs/release-13.html
> >>
> >> It still needs markup, word wrap, and indenting.  The community doc
> >> build should happen in a few hours.
> >
> >
> > There is not note about new polymorphic type "anycompatible"
> >
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=24e2885ee304cb6a94fdfc25a1a108344ed9f4f7
> 
> There's also no note about avoiding full GIN index scan
> (https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4b754d6c16e16cc1a1adf12ab0f48603069a0efd).
> That's a corner case optimization but it can be a huge improvement
> when you hit the problem.

OK, I have added this item:

    Allow GIN indexes to more efficiently handle NOT restrictions (Nikita
    Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud)

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 10:07:35AM +0200, Juan José Santamaría Flecha wrote:
> 
> On Tue, May 5, 2020 at 5:16 AM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     I have committed the first draft of the PG 13 release notes.  You can
>     see them here:
> 
>             https://momjian.us/pgsql_docs/release-13.html
> 
>     It still needs markup, word wrap, and indenting.  The community doc
>     build should happen in a few hours.
> 
>  
> There is one entry "Add support for collation versions on Windows" where I am
> quoted as author. Actually, I was a reviewer, the author is Thomas Munro.

Oops, my mistake, fixed.

> 
> Also, I am credited as sole author of "Allow to_date/to_timestamp to recognize
> non-English month/day names", when the case is that Tom Lane did more than a
> few cosmetics changes when committing and I think he should be quoted as
> co-author (if he agrees).

OK, updated.  The text was:

        Juan José Santamaría Flecha, reviewed and modified by me,

and with reviewed first, and the generic term modified, I had assumed
you would the the only one listed.  Fixed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 09:20:39PM +0800, John Naylor wrote:
> Hi Bruce, thanks for working on this again!
> 
> +<para>
> +Allow UTF-8 escapes, e.g., E'\u####', in clients that don't use UTF-8
> encoding (Tom Lane)
> +</para>
> 
> I believe the term we want here is "Unicode escapes". This patch is
> about the server encoding, which formerly needed to be utf-8 for
> non-ascii characters. (I think the client encoding doesn't matter as
> long as ascii bytes are represented.)
> 
> +<para>
> +The UTF-8 characters must be available in the server encoding.
> +</para>
> 
> Same here, s/UTF-8/Unicode/.

OK, new text is:

    Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
    encoding (Tom Lane)
    
    The Unicode characters must be available in the server encoding.

I kept the "UTF-8 encoding" since that is the only Unicode encoding we
support.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-05, Bruce Momjian wrote:

> On Tue, May  5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:

> > I do not see a "documentation" section, whereas there has been significant
> > doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen,
> 
> I did list the glossary.

Please do list Jürgen, Corey and Roger as authors of the glossary.

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



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
In this item

+<listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2020-04-20 [5fc703946] Add ALTER .. NO DEPENDS ON
+-->
+
+<para>
+Add the ability to remove a function's dependency on an extension (Alvaro Herrera)
+</para>
+
+<para>
+The syntax is ALTER FUNCTION .. NO DEPENDS ON.
+</para>
+
+</listitem>

This works for several object types, not just a functions.  I propose

  Add the ability to remove an object's dependency on an extension (Álvaro Herrera)

  The object can be a function, materialized view, index, or trigger.
  The syntax is ALTER .. NO DEPENDS ON.

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



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-05, Alvaro Herrera wrote:

> On 2020-May-05, Bruce Momjian wrote:
> 
> > On Tue, May  5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
> 
> > > I do not see a "documentation" section, whereas there has been significant
> > > doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen,
> > 
> > I did list the glossary.
> 
> Please do list Jürgen, Corey and Roger as authors of the glossary.

(Actually I should be listed as well, as the time I spent on it was
considerable.)

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



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 11:14:11AM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
> 
> > On Tue, May  5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
> 
> > > I do not see a "documentation" section, whereas there has been significant
> > > doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen,
> > 
> > I did list the glossary.
> 
> Please do list Jürgen, Corey and Roger as authors of the glossary.

Done, from the commit message:

    Add a glossary to the documentation (Corey Huinker, Jürgen Purtz, Roger
    Harkavy, Álvaro Herrera)

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 11:23:50AM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Alvaro Herrera wrote:
> 
> > On 2020-May-05, Bruce Momjian wrote:
> > 
> > > On Tue, May  5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote:
> > 
> > > > I do not see a "documentation" section, whereas there has been significant
> > > > doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen,
> > > 
> > > I did list the glossary.
> > 
> > Please do list Jürgen, Corey and Roger as authors of the glossary.
> 
> (Actually I should be listed as well, as the time I spent on it was
> considerable.)

Yep, already done, based on the commit text.  :-)

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Andrew Dunstan
Date:
On 5/4/20 11:16 PM, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>     https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.
>


Peter Eisentraut gets the credit for Unix domain sockets on Windows, not
me, I just reviewed it.


cheers


andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 11:48:47AM -0400, Andrew Dunstan wrote:
> 
> On 5/4/20 11:16 PM, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >     https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> >
> 
> 
> Peter Eisentraut gets the credit for Unix domain sockets on Windows, not
> me, I just reviewed it.

Sorry about that, fixed.


-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Corey Huinker
Date:

>
> Please do list Jürgen, Corey and Roger as authors of the glossary.

(Actually I should be listed as well, as the time I spent on it was
considerable.)

+1, the time spent was quite considerable 

Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
|Release date: 2020-05-03
=> Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.

|These triggers cannot change the destination partition. 
=> Maybe say "cannot change which partition is the destination"

|Allow incremental sorting (James Coleman, Alexander Korotkov) 
s/Allow/Implement/ ?

|If a result is already sorted by several keys,
s/keys/leading keys/

| Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis) 
|  Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled by
enable_hashagg_disk.
 
=> enable_hashagg_disk doesn't behave like other enable_* parameters.
As I understand, disabling it only "opportunisitically" avoids plans which are
*expected* to overflow work_mem.  I think we should specifically say that, and
maybe suggest recalibrating work_mem.

|This new behavior sets pages as all-visible
I think it should say "can allow setting pages all-visible"
It doesn't do anything special to force anything to be allvisible.

| This is controlled by GUC wal_skip_threshold. 
I think you should say that's a size threshold which determines which strategy
to use (WAL or fsync).

|  Improve the performance of replay of DROP DATABASE commands that use many tablespaces (Fujii Masao) 
"when replaying DROP DATABASE commands if many tablespaces are in use"

|Improve performance for truncation of very larger relations (Kirk Jamison) 
*large

|Server variable backtrace_functions specifies which C functions should generate backtraces on error. 
Could you say "GUC" so it's easy to search for ?

| This is controlled by ssl_min_protocol_version. 
| This behavior can be enabled using wal_receiver_create_temp_slot. 
|  This is controlled by logical_decoding_work_mem. 
|  This is enabled using ignore_invalid_pages. 
Say GUC in these places, too ?

|Previously, server restart was required to change primary_conninfo and primary_slot_name. 
*a* server restart

| Speedup recovery by prefetching pages (Thomas Munro) 
"Speed up" or accelerate or "Improve speed of".
Speedup (one word) sounds like a noun.

| Fix bugs in ALTER TABLE where later clauses overlap changes made by earlier clauses in the same command (Tom Lane) 
s/where/when/ ?

| The new function, jsonb_set_lax(), allows null new values to either set the specified key to JSON null, delete the
key,raise exception, or ignore operation. IS 'return_target' CLEAR? 
 
ignore *the* operation

| time zone-aware output. 
timezone-aware ?

| This makes \gx equivalent to \g (expanded=on). 
I would say: "this allows syntax like \g (expand=on) which is equivalent to \gx"

|Allow pgbench to partition its 'accounts' table (Fabien COELHO) 
Sometimes Fabien's name is/not capitalized.

| This is enable using the -c/--restore-target-wal option. 
*enabled*

| These long-supported options for this are called --superuser and --no-superuser. 
"The supported" not "These long-supported" ?

I'm not sure, but maybe these patches of mine should be documented?

commit 24f62e93f314c107b4fa679869e5ba9adb2d545f
    Improve psql's \d output for partitioned indexes.

commit c33869cc3bfc42bce822251f2fa1a2a346f86cc5
    psql \d: Display table where trigger is defined, if inherited

=> Alvaro said the functionality could conceivably be backpatched
(nontrivially), which suggests this doesn't need to be documented, but I think
backpatch would be a bad idea, and I think it should be documented.

-- 
Justin



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 11:45:03AM -0500, Justin Pryzby wrote:
> |Release date: 2020-05-03
> => Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.

Agreed!

> |These triggers cannot change the destination partition. 
> => Maybe say "cannot change which partition is the destination"
> 
> |Allow incremental sorting (James Coleman, Alexander Korotkov) 
> s/Allow/Implement/ ?

Agreed.

> |If a result is already sorted by several keys,
> s/keys/leading keys/

Agreed.

> | Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis) 
> |  Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled
byenable_hashagg_disk. 
 
> => enable_hashagg_disk doesn't behave like other enable_* parameters.
> As I understand, disabling it only "opportunisitically" avoids plans which are
> *expected* to overflow work_mem.  I think we should specifically say that, and
> maybe suggest recalibrating work_mem.

I went with "avoided":

    Previously, hash aggregation was avoided if it was expected to use more
    than work_mem memory.  This is controlled by enable_hashagg_disk.

> |This new behavior sets pages as all-visible
> I think it should say "can allow setting pages all-visible"
> It doesn't do anything special to force anything to be allvisible.

OK, updated to:

    This new behavior allows pages to be set as all-visible, which then
    allows index-only scans, and reduces the work necessary when the table
    needs to be frozen.

> | This is controlled by GUC wal_skip_threshold. 
> I think you should say that's a size threshold which determines which strategy
> to use (WAL or fsync).

I went with:

    The WAL write amount where this happens is controlled by wal_skip_threshold.

They can use the doc link if they want more detail.

> |  Improve the performance of replay of DROP DATABASE commands that use many tablespaces (Fujii Masao) 
> "when replaying DROP DATABASE commands if many tablespaces are in use"

OK, updated to:

    Improve the performance when replaying DROP DATABASE commands when many
    tablespaces are in use (Fujii Masao)

> 
> |Improve performance for truncation of very larger relations (Kirk Jamison) 
> *large

Fixed.

> |Server variable backtrace_functions specifies which C functions should generate backtraces on error. 
> Could you say "GUC" so it's easy to search for ?

Uh, I kind of back and forth on whether GUC or server variable is
better.  I kind of mix them up so people will know what GUC is.

> | This is controlled by ssl_min_protocol_version. 
> | This behavior can be enabled using wal_receiver_create_temp_slot. 
> |  This is controlled by logical_decoding_work_mem. 
> |  This is enabled using ignore_invalid_pages. 
> Say GUC in these places, too ?

Oh, uh, I am not sure.  These will all have links too.

> |Previously, server restart was required to change primary_conninfo and primary_slot_name. 
> *a* server restart

Agreed.

> | Speedup recovery by prefetching pages (Thomas Munro) 
> "Speed up" or accelerate or "Improve speed of".
> Speedup (one word) sounds like a noun.

Uh, someone requested I remove that, so I have.
> 
> | Fix bugs in ALTER TABLE where later clauses overlap changes made by earlier clauses in the same command (Tom Lane)

> s/where/when/ ?

Agreed.

> | The new function, jsonb_set_lax(), allows null new values to either set the specified key to JSON null, delete the
key,raise exception, or ignore operation. IS 'return_target' CLEAR? 
 
> ignore *the* operation

Agreed.

> | time zone-aware output. 
> timezone-aware ?

Uh, time zone is two words.  We can do time-zone-aware but that looks
odd.

> | This makes \gx equivalent to \g (expanded=on). 
> I would say: "this allows syntax like \g (expand=on) which is equivalent to \gx"

I like that.

> |Allow pgbench to partition its 'accounts' table (Fabien COELHO) 
> Sometimes Fabien's name is/not capitalized.

I have already committed a fix for that.

> | This is enable using the -c/--restore-target-wal option. 
> *enabled*

Agreed.

> | These long-supported options for this are called --superuser and --no-superuser. 
> "The supported" not "These long-supported" ?

Yep.

> I'm not sure, but maybe these patches of mine should be documented?
> 
> commit 24f62e93f314c107b4fa679869e5ba9adb2d545f
>     Improve psql's \d output for partitioned indexes.
> 
> commit c33869cc3bfc42bce822251f2fa1a2a346f86cc5
>     psql \d: Display table where trigger is defined, if inherited
> 
> => Alvaro said the functionality could conceivably be backpatched
> (nontrivially), which suggests this doesn't need to be documented, but I think
> backpatch would be a bad idea, and I think it should be documented.

I looked at these and they looked like incremental changes to psql
display in a way that people would say "nice", but not really want to
know about it before-hand.  Maybe I am wrong.

Thanks for all your fixes, all committed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Tue, May 05, 2020 at 01:18:09PM -0400, Bruce Momjian wrote:
> > |Release date: 2020-05-03
> > => Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.
> 
> Agreed!
> 
> > |These triggers cannot change the destination partition. 
> > => Maybe say "cannot change which partition is the destination"

Looks like you copied my quote mark :(

> > | Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis) 
> > |  Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is
controlledby enable_hashagg_disk. 
 
> > => enable_hashagg_disk doesn't behave like other enable_* parameters.
> > As I understand, disabling it only "opportunisitically" avoids plans which are
> > *expected* to overflow work_mem.  I think we should specifically say that, and
> > maybe suggest recalibrating work_mem.
> 
> I went with "avoided":
> 
>     Previously, hash aggregation was avoided if it was expected to use more
>     than work_mem memory.  This is controlled by enable_hashagg_disk.

I think we should expand on this:

|Previously, hash aggregation was avoided if it was expected to use more than
|work_mem memory, but it wasn't enforced, and hashing could still exceed
|work_mem.  To get back the old behavior, increasing work_mem.
|
|The parameter enable_hashagg_disk controls whether a plan which is *expected*
|to spill to disk will be considered.  During execution, an aggregate node which
|exceeding work_mem will spill to disk regardless of this parameter.

I wrote something similar here:
https://www.postgresql.org/message-id/20200407223900.GT2228%40telsasoft.com

> > | This is controlled by GUC wal_skip_threshold. 
> > I think you should say that's a size threshold which determines which strategy
> > to use (WAL or fsync).
> 
> I went with:
>     The WAL write amount where this happens is controlled by wal_skip_threshold.
>
> They can use the doc link if they want more detail.

I guess I would say "relations larger than wal_skip_threshold will be fsynced
rather than copied to WAL"

-- 
Justin



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
Do you want to include any of these?

5823677acc Provide pgbench --show-script to dump built-in scripts.
ce8f946764 Report the time taken by pgbench initialization steps.
751c63cea0 Remove pg_regress' --load-language option.
33753ac9d7 Add object names to partition integrity violations.
246f136e76 Improve handling of parameter differences in physical replication
a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
2fc2a88e67 Remove obsolete information schema tables
b9b408c487 Record parents of triggers (tgparentid)
2b2bacdca0 Reset statement_timeout between queries of a multi-query string.
09f08930f0 initdb: Change authentication defaults Change the defaults for the pg_hba.conf generated by initdb to "peer"
or"md5"
 

>Improve control of prepared statement parameter logging 
>The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement
logging,and log_parameter_max_length_on_error allows parameters to be output on
 
I think the original commit (ba79cb5d) gets lost in the description of the
details and the following commit.  I would say:
|Emit parameter values during query bind/execute errors and allow control of the max length logged by statement logging
(AlexeyBashtanov, Álvaro Herrera)
 
|The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement
logging,and log_parameter_max_length_on_error allows parameters to be output on
 
|error.
Or maybe split that into two items.

> Allow track_activity_query_size to be set to 1MB (Vyacheslav Makarov)
Say "*up* to 1MB".

> super users
say "superuser" ?

>Allow allow_system_table_mods to be changed after server start (Peter Eisentraut)
>Disallow non-super users from modifying system tables when allow_system_table_mods is set (Peter Eisentraut) 
I think these two entries can be merged.

>Add parallel control of the vacuumdb command using --parallel (Masahiko Sawada)
>Allow reindexdb to operate in parallel (Julien Rouhaud)
>Parallel mode is enabled with the new --jobs option. 

It's probably worth saying that vacuumdb --parallel just passes (parallel N)
option to the vacuum command, which means that it processes indexes in parallel.
Whereas reindexdb --jobs is a client-side feature, creating a separate sessions
for each.

-- 
Justin



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 12:50:01PM -0500, Justin Pryzby wrote:
> On Tue, May 05, 2020 at 01:18:09PM -0400, Bruce Momjian wrote:
> > > |Release date: 2020-05-03
> > > => Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight.
> > 
> > Agreed!
> > 
> > > |These triggers cannot change the destination partition. 
> > > => Maybe say "cannot change which partition is the destination"
> 
> Looks like you copied my quote mark :(

I kind of liked it, but OK, removed.  ;-)

> > > | Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis) 
> > > |  Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is
controlledby enable_hashagg_disk. 
 
> > > => enable_hashagg_disk doesn't behave like other enable_* parameters.
> > > As I understand, disabling it only "opportunisitically" avoids plans which are
> > > *expected* to overflow work_mem.  I think we should specifically say that, and
> > > maybe suggest recalibrating work_mem.
> > 
> > I went with "avoided":
> > 
> >     Previously, hash aggregation was avoided if it was expected to use more
> >     than work_mem memory.  This is controlled by enable_hashagg_disk.
> 
> I think we should expand on this:
> 
> |Previously, hash aggregation was avoided if it was expected to use more than
> |work_mem memory, but it wasn't enforced, and hashing could still exceed
> |work_mem.  To get back the old behavior, increasing work_mem.

I think work_mem has too many other effects to recommend just changing
it for this.

> |The parameter enable_hashagg_disk controls whether a plan which is *expected*
> |to spill to disk will be considered.  During execution, an aggregate node which
> |exceeding work_mem will spill to disk regardless of this parameter.
> 
> I wrote something similar here:
> https://www.postgresql.org/message-id/20200407223900.GT2228%40telsasoft.com

I think this kind of information should be in our docs, not really the
release notes.

> > > | This is controlled by GUC wal_skip_threshold. 
> > > I think you should say that's a size threshold which determines which strategy
> > > to use (WAL or fsync).
> > 
> > I went with:
> >     The WAL write amount where this happens is controlled by wal_skip_threshold.
> >
> > They can use the doc link if they want more detail.
> 
> I guess I would say "relations larger than wal_skip_threshold will be fsynced
> rather than copied to WAL"

How is this?

    Relations larger than wal_skip_threshold will have their files fynsced
    rather than writing their WAL records.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> Do you want to include any of these?
> 
> 5823677acc Provide pgbench --show-script to dump built-in scripts.
> ce8f946764 Report the time taken by pgbench initialization steps.

I am kind of unclear how much of pgbench changes to put in the release
notes since the use seems so specialized, but maybe that is wrong.

> 751c63cea0 Remove pg_regress' --load-language option.

Well, for the same reasons, that is our regression tests, which I assume
is more for internal use.

> 33753ac9d7 Add object names to partition integrity violations.

Improving error messages is not something I usually cover.   People like
to see the better error messages, but don't really value knowing about
them before-hand, I am guessing.

> 246f136e76 Improve handling of parameter differences in physical replication

That seems to fall in the category above.

> a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517

Uh, that didn't seem significant.

> 2fc2a88e67 Remove obsolete information schema tables
> b9b408c487 Record parents of triggers (tgparentid)
> 2b2bacdca0 Reset statement_timeout between queries of a multi-query string.

That seemed like a bug fix for unusual usage.

> 09f08930f0 initdb: Change authentication defaults Change the defaults for the pg_hba.conf generated by initdb to
"peer"or "md5"
 

Uh, that was reverted:

    Author: Peter Eisentraut <peter@eisentraut.org>
    2019-07-22 [796188658] Revert "initdb: Change authentication defaults"
    
        Revert "initdb: Change authentication defaults"
    
        This reverts commit 09f08930f0f6fd4a7350ac02f29124b919727198.
    
        The buildfarm client needs some adjustments first.

> >Improve control of prepared statement parameter logging 
> >The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement
logging,and log_parameter_max_length_on_error allows parameters to be output on
 
> I think the original commit (ba79cb5d) gets lost in the description of the
> details and the following commit.  I would say:
> |Emit parameter values during query bind/execute errors and allow control of the max length logged by statement
logging(Alexey Bashtanov, Álvaro Herrera)
 
> |The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement
logging,and log_parameter_max_length_on_error allows parameters to be output on
 
> |error.
> Or maybe split that into two items.

I struggled on this one because we are both limiting parameter length
when logging of normal queries _and_ adding paramater logging of error
queries, also with a length limit.

I tried a few approaches but ended up with this:

    Improve control of prepared statement parameter logging (Alexey
    Bashtanov, Álvaro Herrera)

    The GUC setting log_parameter_max_length controls the maximum
    length of parameter values output during statement non-error
    logging, and log_parameter_max_length_on_error does the same
    for error statement logging.  Previously, prepared statement
    parameters were not logged during errors.

> > Allow track_activity_query_size to be set to 1MB (Vyacheslav Makarov)
> Say "*up* to 1MB".

Agreed.

> > super users
> say "superuser" ?

All fixed, thanks.

> >Allow allow_system_table_mods to be changed after server start (Peter Eisentraut)
> >Disallow non-super users from modifying system tables when allow_system_table_mods is set (Peter Eisentraut) 
> I think these two entries can be merged.

Uh, they are quite different.  The first one is about not requiring a
reboot, while the second is a fix for allowing users do things when it
is set that they should not be able to do.

> >Add parallel control of the vacuumdb command using --parallel (Masahiko Sawada)
> >Allow reindexdb to operate in parallel (Julien Rouhaud)
> >Parallel mode is enabled with the new --jobs option. 
> 
> It's probably worth saying that vacuumdb --parallel just passes (parallel N)
> option to the vacuum command, which means that it processes indexes in parallel.
> Whereas reindexdb --jobs is a client-side feature, creating a separate sessions
> for each.

Oh, wow, good point, and very subtle.  I used this text:

    Allow vacuum commands run by vacuumdb to operate in parallel mode
    (Masahiko Sawada)
    
    This is enabled with the new --parallel option.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Jeff Davis
Date:
On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
> 
>     https://momjian.us/pgsql_docs/release-13.html
> 
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Regarding grouping sets:

Just like hash aggregation, grouping sets could exceed work_mem by
large amounts in v12. Now, in v13, they both use disk when appropriate.

There's an open item where we will consider tweaking the GUCs, so the
descriptions might change slightly.

Regards,
    Jeff Davis





Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote:
> > > > | This is controlled by GUC wal_skip_threshold. 
> > > > I think you should say that's a size threshold which determines which strategy
> > > > to use (WAL or fsync).
> > > 
> > > I went with:
> > >     The WAL write amount where this happens is controlled by wal_skip_threshold.
> > >
> > > They can use the doc link if they want more detail.
> > 
> > I guess I would say "relations larger than wal_skip_threshold will be fsynced
> > rather than copied to WAL"
> 
> How is this?
> 
>     Relations larger than wal_skip_threshold will have their files fynsced
>     rather than writing their WAL records.

I see I was too late, but:

Fix typo (fynsc) and maybe add parens().

-- 
Justin



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-05, Bruce Momjian wrote:

> > |Allow incremental sorting (James Coleman, Alexander Korotkov) 
> > s/Allow/Implement/ ?
> 
> Agreed.

FWIW I think Tomas Vondra should be credited as coauthor of this
feature.  He didn't list himself as author in the commit message but I'm
pretty sure that's out of modesty, not lack of contribution.

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



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-05, Bruce Momjian wrote:

> On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > Do you want to include any of these?
> > 
> > 5823677acc Provide pgbench --show-script to dump built-in scripts.
> > ce8f946764 Report the time taken by pgbench initialization steps.
> 
> I am kind of unclear how much of pgbench changes to put in the release
> notes since the use seems so specialized, but maybe that is wrong.

Maybe it would make sense to group all pgbench changes in a subsection
of their own?

> > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
> > 2fc2a88e67 Remove obsolete information schema tables
> 
> Uh, that didn't seem significant.

Maybe have one item "modernize information_schema", and then describe
all the changes together in a single item.

> I tried a few approaches but ended up with this:
> 
>     Improve control of prepared statement parameter logging (Alexey
>     Bashtanov, Álvaro Herrera)
> 
>     The GUC setting log_parameter_max_length controls the maximum
>     length of parameter values output during statement non-error
>     logging, and log_parameter_max_length_on_error does the same
>     for error statement logging.  Previously, prepared statement
>     parameters were not logged during errors.

This seems good to me.  I think Tom Lane should be listed as coauthor of
this item.

> I used this text:
> 
>     Allow vacuum commands run by vacuumdb to operate in parallel mode
>     (Masahiko Sawada)
>     
>     This is enabled with the new --parallel option.

I think the vacuumdb item should be merged with the item for 40d964ec9,
since this is just about vacuumdb gaining control of the new VACUUM
feature.  It's not something you can use separately from that.

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



Re: PG 13 release notes, first draft

From
David Steele
Date:
On 5/5/20 3:21 PM, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
> 
>>> |Allow incremental sorting (James Coleman, Alexander Korotkov)
>>> s/Allow/Implement/ ?
>>
>> Agreed.
> 
> FWIW I think Tomas Vondra should be credited as coauthor of this
> feature.  He didn't list himself as author in the commit message but I'm
> pretty sure that's out of modesty, not lack of contribution.

+1.

-- 
-David
david@pgmasters.net



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Tue, May 05, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
> > On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > > Do you want to include any of these?
> > > 
> > > 5823677acc Provide pgbench --show-script to dump built-in scripts.
> > > ce8f946764 Report the time taken by pgbench initialization steps.
> > 
> > I am kind of unclear how much of pgbench changes to put in the release
> > notes since the use seems so specialized, but maybe that is wrong.
> 
> Maybe it would make sense to group all pgbench changes in a subsection
> of their own?
> 
> > > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
> > > 2fc2a88e67 Remove obsolete information schema tables
> > 
> > Uh, that didn't seem significant.
> 
> Maybe have one item "modernize information_schema", and then describe
> all the changes together in a single item.

FYI, I did the same as last year, so I found these from output of something
like git log --cherry-pick REL_12_STABLE...master
I asked to avoid false negatives, not because I specifically want those commits
mentioned.

> > I used this text:
> > 
> >     Allow vacuum commands run by vacuumdb to operate in parallel mode
> >     (Masahiko Sawada)
> >     
> >     This is enabled with the new --parallel option.
> 
> I think the vacuumdb item should be merged with the item for 40d964ec9,
> since this is just about vacuumdb gaining control of the new VACUUM
> feature.  It's not something you can use separately from that.

+1

-- 
Justin



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 11:44:33AM -0700, Jeff Davis wrote:
> On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> > 
> >     https://momjian.us/pgsql_docs/release-13.html
> > 
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Regarding grouping sets:
> 
> Just like hash aggregation, grouping sets could exceed work_mem by
> large amounts in v12. Now, in v13, they both use disk when appropriate.

Oh, another place I should change "not used" to "avoided".  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 01:45:37PM -0500, Justin Pryzby wrote:
> On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote:
> > > > > | This is controlled by GUC wal_skip_threshold. 
> > > > > I think you should say that's a size threshold which determines which strategy
> > > > > to use (WAL or fsync).
> > > > 
> > > > I went with:
> > > >     The WAL write amount where this happens is controlled by wal_skip_threshold.
> > > >
> > > > They can use the doc link if they want more detail.
> > > 
> > > I guess I would say "relations larger than wal_skip_threshold will be fsynced
> > > rather than copied to WAL"
> > 
> > How is this?
> > 
> >     Relations larger than wal_skip_threshold will have their files fynsced
> >     rather than writing their WAL records.
> 
> I see I was too late, but:
> 
> Fix typo (fynsc) and maybe add parens().

Ah, I was looking for fsync to fix that and could not find it.   Now I
found it with that spelling,  I ended up using "fsync'ed".

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 03:21:00PM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
> 
> > > |Allow incremental sorting (James Coleman, Alexander Korotkov) 
> > > s/Allow/Implement/ ?
> > 
> > Agreed.
> 
> FWIW I think Tomas Vondra should be credited as coauthor of this
> feature.  He didn't list himself as author in the commit message but I'm
> pretty sure that's out of modesty, not lack of contribution.

Thanks, added.  We will hunt that modesty down!  LOL

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote:
> On 2020-May-05, Bruce Momjian wrote:
> 
> > On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > > Do you want to include any of these?
> > > 
> > > 5823677acc Provide pgbench --show-script to dump built-in scripts.
> > > ce8f946764 Report the time taken by pgbench initialization steps.
> > 
> > I am kind of unclear how much of pgbench changes to put in the release
> > notes since the use seems so specialized, but maybe that is wrong.
> 
> Maybe it would make sense to group all pgbench changes in a subsection
> of their own?

pgbench already has its own section in the docs:

    E.1.3.8.2. pgbench

I would be glad to expand it since it is easy to pick out pgbench items
from the commit logs.

> > > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
> > > 2fc2a88e67 Remove obsolete information schema tables
> > 
> > Uh, that didn't seem significant.
> 
> Maybe have one item "modernize information_schema", and then describe
> all the changes together in a single item.

Uh, so I am unclear when we are adding items to information_schema
because we now support them, and when they are new features of
information_schema.

> > I tried a few approaches but ended up with this:
> > 
> >     Improve control of prepared statement parameter logging (Alexey
> >     Bashtanov, Álvaro Herrera)
> > 
> >     The GUC setting log_parameter_max_length controls the maximum
> >     length of parameter values output during statement non-error
> >     logging, and log_parameter_max_length_on_error does the same
> >     for error statement logging.  Previously, prepared statement
> >     parameters were not logged during errors.
> 
> This seems good to me.  I think Tom Lane should be listed as coauthor of
> this item.

Added.

> > I used this text:
> > 
> >     Allow vacuum commands run by vacuumdb to operate in parallel mode
> >     (Masahiko Sawada)
> >     
> >     This is enabled with the new --parallel option.
> 
> I think the vacuumdb item should be merged with the item for 40d964ec9,
> since this is just about vacuumdb gaining control of the new VACUUM
> feature.  It's not something you can use separately from that.

Well, it is under Server Commands and has a new flag, so I thought it
should be here.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-May-05, Bruce Momjian wrote:
>> I tried a few approaches but ended up with this:
>> 
>> Improve control of prepared statement parameter logging (Alexey
>> Bashtanov, Álvaro Herrera)
>> 
>> The GUC setting log_parameter_max_length controls the maximum
>> length of parameter values output during statement non-error
>> logging, and log_parameter_max_length_on_error does the same
>> for error statement logging.  Previously, prepared statement
>> parameters were not logged during errors.

> This seems good to me.  I think Tom Lane should be listed as coauthor of
> this item.

Not necessary, I didn't do much on that.

            regards, tom lane



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
> On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > Do you want to include any of these?
> > 
> > 5823677acc Provide pgbench --show-script to dump built-in scripts.

I have added the above entry to the release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 05:31:26PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2020-May-05, Bruce Momjian wrote:
> >> I tried a few approaches but ended up with this:
> >> 
> >> Improve control of prepared statement parameter logging (Alexey
> >> Bashtanov, Álvaro Herrera)
> >> 
> >> The GUC setting log_parameter_max_length controls the maximum
> >> length of parameter values output during statement non-error
> >> logging, and log_parameter_max_length_on_error does the same
> >> for error statement logging.  Previously, prepared statement
> >> parameters were not logged during errors.
> 
> > This seems good to me.  I think Tom Lane should be listed as coauthor of
> > this item.
> 
> Not necessary, I didn't do much on that.

OK, removed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote:
> On Tue, May  5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
> > On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > > Do you want to include any of these?
> > > 
> > > 5823677acc Provide pgbench --show-script to dump built-in scripts.
> 
> I have added the above entry to the release notes.

+2019-07-16 [ce8f94676] Report the time taken by pgbench initialization steps.
+Allow pgbench to dump script contents using --show-script (Fabien Coelho)

I think you confused these?

ce8f946764 Report the time taken by pgbench initialization steps.
5823677acc Provide pgbench --show-script to dump built-in scripts.

-- 
Justin



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 04:39:58PM -0500, Justin Pryzby wrote:
> On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote:
> > On Tue, May  5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote:
> > > On Tue, May  5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote:
> > > > Do you want to include any of these?
> > > > 
> > > > 5823677acc Provide pgbench --show-script to dump built-in scripts.
> > 
> > I have added the above entry to the release notes.
> 
> +2019-07-16 [ce8f94676] Report the time taken by pgbench initialization steps.
> +Allow pgbench to dump script contents using --show-script (Fabien Coelho)
> 
> I think you confused these?
> 
> ce8f946764 Report the time taken by pgbench initialization steps.
> 5823677acc Provide pgbench --show-script to dump built-in scripts.

You are correct, fixed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Bruce,

>> * "DOCUMENT THE DEFAULT GENERATION METHOD"
>>   => The default is still to generate data client-side.
>
> My point is that the docs are not clear about this.

Indeed.

> Can you fix it?

Sure. Attached patch adds an explicit sentence about it, as it was only 
hinted about in the default initialization command string, and removes a 
spurious empty paragraph found nearby.

-- 
Fabien.
Attachment

Re: PG 13 release notes, first draft

From
"Andrey M. Borodin"
Date:

> 5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
>
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>     https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything
pglz-compressed)decompression should be significantly faster in v13. 
https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06

Best regards, Andrey Borodin.


Re: PG 13 release notes, first draft

From
Noah Misch
Date:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)

Kyotaro Horiguchi authored that one.  (I committed it.)  The commit message
noted characteristics, some of which may deserve mention in the notes:

- Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
- Out-of-tree table access methods will require changes.
- Users setting a timeout on COMMIT may need to adjust that timeout, and
  log_min_duration_statement analysis will reflect time consumption moving to
  COMMIT from commands like COPY.
- COPY has worked this way for awhile; this extends it to all modifications.



Re: PG 13 release notes, first draft

From
Alexander Korotkov
Date:
On Tue, May 5, 2020 at 6:16 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html

Great, thank you!

It seems that opclass parameters (911e702077) are not reflected in the
release notes.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



Re: PG 13 release notes, first draft

From
Amit Langote
Date:
Hi Bruce,

On Tue, May 5, 2020 at 12:16 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thanks for this as always.

+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much
+-->
+
+<para>
+Improve cases where pruning of partitions can happen (Amit Langote,
Yuzuko Hosoya, Álvaro Herrera)
+</para>

The following commit should be included with this item:

commit 489247b0e615592111226297a0564e11616361a5
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:   Sun Aug 4 11:18:45 2019 -0400

    Improve pruning of a default partition

Primary author for this commit and the person who raised various
problems that led to these improvements is Yuzuko Hosoya. So I think
her name should go first.

+Author: Etsuro Fujita <efujita@postgresql.org>
+2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
+-->
+
+<para>
+Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
Etsuro Fujita, Amit Langote)
+</para>

Maybe it would be better to break this into two items, because while
c8434d64c is significant new functionality that I only contributed a
few review comments towards, 981643dcd is relatively minor surgery of
partitionwise join code to handle FULL JOINs correctly.  Tom's rewrite
of my patch for the latter was pretty significant too, so maybe better
to list his name as well.

+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
+-->
+
+<para>
+Allow logical replication to replicate partitioned tables (Amit Langote)
+</para>
+
+</listitem>
+
+<listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
+-->
+
+<para>
+Allow partitioned tables to be added to replicated publications (Amit Langote)
+</para>
+
+<para>
+Partition additions/removals are replicated as well.  Previously,
partitions had to be replicated individually.  HOW IS THIS DIFFERENT
FROM THE ITEM ABOVE?
+</para>

The former is subscription-side new functionality and the latter is
publication-side and the two are somewhat independent.

Till now, logical replication could only occur between relkind 'r'
relations. So the only way to keep a given partitioned table in sync
on the two servers was to manually add the leaf partitions (of relkind
'r') to a publication and also manually keep the list of replicated
tables up to date as partitions come and go, that is, by
adding/removing them to/from the publication.

17b9e7f9f (the second item) makes it possible for the partitioned
table (relkind 'p') to be added to the publication so that individual
leaf partitions need not be manually kept in the publication.
Replication still flows between the leaf partitions (relkind 'r'
relations) though.

f1ac27bfd (the first item) makes is possible to replicate from a
regular table (relkind 'r') into a partitioned table (relkind 'p').
If a given row is replicated into a partitioned table, the
subscription worker will route it to the correct leaf partition of
that partitioned table.

+<listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
+-->
+
+<para>
+Allow CREATE PUBLICATION to control whether partitioned tables are
published as themselves or their ancestors (Amit Langote)
+</para>
+
+<para>
+The option is publish_via_partition_root.
+</para>

And this allows replication to optionally originate from relkind 'p'
relations on the publication server, whereas it could previously only
originate from relkind 'r' relations.  Combined with the first item,
users can now replicate between partitioned tables that have a
different set of partitions on the two servers.

Maybe it would make sense to combine the three into one item:

<para>
Add support for logical replication of partitioned tables
</para>

<para>
Logical replication can now occur between partitioned tables, where
previously it would only be allowed between regular tables. A new
publication option <literal>publish_via_partition_root</literal>
controls whether a leaf partition's changes are published as its own
or as that of the ancestor that's actually published.
</para>

--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



Re: PG 13 release notes, first draft

From
Chapman Flack
Date:
On 05/05/20 10:31, Bruce Momjian wrote:
> On Tue, May  5, 2020 at 09:20:39PM +0800, John Naylor wrote:
>> ... This patch is
>> about the server encoding, which formerly needed to be utf-8 for
>> non-ascii characters. (I think the client encoding doesn't matter as
>> long as ascii bytes are represented.)
>>
>> +<para>
>> +The UTF-8 characters must be available in the server encoding.
>> +</para>
>>
>> Same here, s/UTF-8/Unicode/.
> 
> OK, new text is:
> 
>     Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
>     encoding (Tom Lane)
>     
>     The Unicode characters must be available in the server encoding.
> 
> I kept the "UTF-8 encoding" since that is the only Unicode encoding we
> support.

My understanding also was that it matters little to this change what the
/client's/ encoding is.

There used to be a limitation of the server's lexer that would reject
Unicode escapes whenever the /server's/ encoding wasn't UTF-8 (even
if the server's encoding contained the characters the escapes represent).
I think that limitation is what was removed.

I don't think the client encoding comes into it at all. Sure, you could
just include the characters literally if they are in the client encoding,
but you might still choose to express them as escapes, and if you do they
get passed that way to the server for interpretation.

I had assumed the patch applied to all of the forms U&'\####',
U&'\+######', E'\u####', and E'\U######' but I don't think I read
the patch to be sure of that.

Regards,
-Chap



Re: PG 13 release notes, first draft

From
Chapman Flack
Date:
On 05/06/20 16:01, Chapman Flack wrote:
> I had assumed the patch applied to all of the forms U&'\####',
> U&'\+######', E'\u####', and E'\U######' ...

annnd that last form needs to have eight #s. (Can't be respelled with 4 ♭s.)


-Chap



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May  6, 2020 at 07:36:21AM +0200, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> > > * "DOCUMENT THE DEFAULT GENERATION METHOD"
> > >   => The default is still to generate data client-side.
> > 
> > My point is that the docs are not clear about this.
> 
> Indeed.
> 
> > Can you fix it?
> 
> Sure. Attached patch adds an explicit sentence about it, as it was only
> hinted about in the default initialization command string, and removes a
> spurious empty paragraph found nearby.

Thanks, patch applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May  6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> 
> 
> > 5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
> > 
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> > 
> >     https://momjian.us/pgsql_docs/release-13.html
> > 
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything
pglz-compressed)decompression should be significantly faster in v13.
 
> https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06

OK, I read the thread mentioned in the commit message and I now see the
value of this change.  Attached is the release note diff.  Let me know
if it needs improvement.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Attachment

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May  5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
> 
> Kyotaro Horiguchi authored that one.  (I committed it.)  The commit message
> noted characteristics, some of which may deserve mention in the notes:

Fixed.

> - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.

This was not backpatched?

> - Out-of-tree table access methods will require changes.

Uh, I don't think we mention those.

> - Users setting a timeout on COMMIT may need to adjust that timeout, and
>   log_min_duration_statement analysis will reflect time consumption moving to
>   COMMIT from commands like COPY.

Uh, not sure how to say that but I don't think we would normally mention that.

> - COPY has worked this way for awhile; this extends it to all modifications.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May  6, 2020 at 03:18:54PM +0300, Alexander Korotkov wrote:
> On Tue, May 5, 2020 at 6:16 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> 
> Great, thank you!
> 
> It seems that opclass parameters (911e702077) are not reflected in the
> release notes.

Uh, I have these items, just not that commit id:

    <listitem>
    <!--
    Author: Alexander Korotkov <akorotkov@postgresql.org>
    2020-03-30 [911e70207] Implement operator class parameters
    -->
    
    <para>
    Allow index operator classes to take parameters (Nikita Glukhov)
    </para>
    
    </listitem>
    
    <listitem>
    <!--
    Author: Alexander Korotkov <akorotkov@postgresql.org>
    2020-03-30 [911e70207] Implement operator class parameters
    -->
    
    <para>
    Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita Glukhov)
    </para>
    
    </listitem>

Is that OK?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote:
> On Wed, May  6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> > I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything
pglz-compressed)decompression should be significantly faster in v13.
 
> > https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06
> 
> OK, I read the thread mentioned in the commit message and I now see the
> value of this change.  Attached is the release note diff.  Let me know
> if it needs improvement.

Sorry I didn't see it earlier, but:

> -Improve retrieving of only the leading bytes of TOAST values (Binguo Bao)
> +Improve speed of TOAST decompression and the retrievel of only the leading bytes of TOAST values (Binguo Bao, Andrey
Borodin)

retrieval

I will include this with my running doc patch if you don't want to make a
separate commit.

-- 
Justin



Re: PG 13 release notes, first draft

From
Noah Misch
Date:
On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
> On Tue, May  5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
> > 
> > Kyotaro Horiguchi authored that one.  (I committed it.)  The commit message
> > noted characteristics, some of which may deserve mention in the notes:
> 
> Fixed.

I don't see that change pushed (but it's not urgent).

> > - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
> 
> This was not backpatched?

Right.

> > - Out-of-tree table access methods will require changes.
> 
> Uh, I don't think we mention those.

Okay.  This point is relatively-important.  On the other hand, the table
access methods known to me have maintainers who follow -hackers.  They may
learn that way.

> > - Users setting a timeout on COMMIT may need to adjust that timeout, and
> >   log_min_duration_statement analysis will reflect time consumption moving to
> >   COMMIT from commands like COPY.
> 
> Uh, not sure how to say that but I don't think we would normally mention that.

Okay.



Re: PG 13 release notes, first draft

From
"Andrey M. Borodin"
Date:

> 7 мая 2020 г., в 04:35, Bruce Momjian <bruce@momjian.us> написал(а):
>
> On Wed, May  6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
>>
>>
>>> 5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
>>>
>>> I have committed the first draft of the PG 13 release notes.  You can
>>> see them here:
>>>
>>>     https://momjian.us/pgsql_docs/release-13.html
>>>
>>> It still needs markup, word wrap, and indenting.  The community doc
>>> build should happen in a few hours.
>>
>> I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything
pglz-compressed)decompression should be significantly faster in v13. 
>> https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06
>
> OK, I read the thread mentioned in the commit message and I now see the
> value of this change.  Attached is the release note diff.  Let me know
> if it needs improvement.

There is one minor typo retrievel -> retrieval.
Thanks!

Best regards, Andrey Borodin.


Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Bruce,

>>>> * "DOCUMENT THE DEFAULT GENERATION METHOD"
>>>>   => The default is still to generate data client-side.
>>>
>>> My point is that the docs are not clear about this.
>>
>> Indeed.
>>
>>> Can you fix it?
>>
>> Sure. Attached patch adds an explicit sentence about it, as it was only
>> hinted about in the default initialization command string, and removes a
>> spurious empty paragraph found nearby.
>
> Thanks, patch applied.

Ok.

You might remove the "DOCUMENT THE DEFAULT…" in the release note.

I'm wondering about the commit comment: "Reported-by: Fabien COELHO", 
actually you reported it, not me!

After looking again at the release notes, I do really think that 
significant documentation changes do not belong to the "Source code" 
section but should be in separate "Documentation" section, and that more 
items should be listed there, because they represent a lot of not-so-fun 
work, especially Tom's restructuration of tables, and possibly others.

About pgbench, ISTM that d37ddb745be07502814635585cbf935363c8a33d is worth 
mentionning because it is a user-visible change.

-- 
Fabien.

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> Hi Bruce,
> 
> On Tue, May 5, 2020 at 12:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Thanks for this as always.
> 
> +Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> +2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin
> +Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> +2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much
> +-->
> +
> +<para>
> +Improve cases where pruning of partitions can happen (Amit Langote,
> Yuzuko Hosoya, Álvaro Herrera)
> +</para>
> 
> The following commit should be included with this item:
> 
> commit 489247b0e615592111226297a0564e11616361a5
> Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> Date:   Sun Aug 4 11:18:45 2019 -0400
> 
>     Improve pruning of a default partition
> 
> Primary author for this commit and the person who raised various
> problems that led to these improvements is Yuzuko Hosoya. So I think
> her name should go first.

OK, I have moved her name to be first.  FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.

    commit 8654407148
    Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
    Date:   Sun Aug 4 11:18:45 2019 -0400
    
        Improve pruning of a default partition
    
        When querying a partitioned table containing a default partition, we
        were wrongly deciding to include it in the scan too early in the
        process, failing to exclude it in some cases.  If we reinterpret the
        PruneStepResult.scan_default flag slightly, we can do a better job at
        detecting that it can be excluded.  The change is that we avoid setting
        the flag for that pruning step unless the step absolutely requires the
        default partition to be scanned (in contrast with the previous
        arrangement, which was to set it unless the step was able to prune it).
        So get_matching_partitions() must explicitly check the partition that
        each returned bound value corresponds to in order to determine whether
        the default one needs to be included, rather than relying on the flag
        from the final step result.
    
        Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
        Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
        Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp

FYI, I don't see backpatched commits when creating the release notes.

> +Author: Etsuro Fujita <efujita@postgresql.org>
> +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
> +Author: Tom Lane <tgl@sss.pgh.pa.us>
> +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
> +-->
> +
> +<para>
> +Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
> Etsuro Fujita, Amit Langote)
> +</para>
> 
> Maybe it would be better to break this into two items, because while
> c8434d64c is significant new functionality that I only contributed a
> few review comments towards, 981643dcd is relatively minor surgery of

What text would we use for the new item?  I thought FULL JOIN was just
another case that matched the description I had.

> partitionwise join code to handle FULL JOINs correctly.  Tom's rewrite
> of my patch for the latter was pretty significant too, so maybe better
> to list his name as well.

OK, I have added Tom's name.

> +<!--
> +Author: Peter Eisentraut <peter@eisentraut.org>
> +2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
> +-->
> +
> +<para>
> +Allow logical replication to replicate partitioned tables (Amit Langote)
> +</para>
> +
> +</listitem>
> +
> +<listitem>
> +<!--
> +Author: Peter Eisentraut <peter@eisentraut.org>
> +2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
> +-->
> +
> +<para>
> +Allow partitioned tables to be added to replicated publications (Amit Langote)
> +</para>
> +
> +<para>
> +Partition additions/removals are replicated as well.  Previously,
> partitions had to be replicated individually.  HOW IS THIS DIFFERENT
> FROM THE ITEM ABOVE?
> +</para>
> 
> The former is subscription-side new functionality and the latter is
> publication-side and the two are somewhat independent.
> 
> Till now, logical replication could only occur between relkind 'r'
> relations. So the only way to keep a given partitioned table in sync
> on the two servers was to manually add the leaf partitions (of relkind
> 'r') to a publication and also manually keep the list of replicated
> tables up to date as partitions come and go, that is, by
> adding/removing them to/from the publication.
> 
> 17b9e7f9f (the second item) makes it possible for the partitioned
> table (relkind 'p') to be added to the publication so that individual
> leaf partitions need not be manually kept in the publication.
> Replication still flows between the leaf partitions (relkind 'r'
> relations) though.
> 
> f1ac27bfd (the first item) makes is possible to replicate from a
> regular table (relkind 'r') into a partitioned table (relkind 'p').
> If a given row is replicated into a partitioned table, the
> subscription worker will route it to the correct leaf partition of
> that partitioned table.

Wow, that is complicated.

> +<listitem>
> +<!--
> +Author: Peter Eisentraut <peter@eisentraut.org>
> +2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
> +-->
> +
> +<para>
> +Allow CREATE PUBLICATION to control whether partitioned tables are
> published as themselves or their ancestors (Amit Langote)
> +</para>
> +
> +<para>
> +The option is publish_via_partition_root.
> +</para>
> 
> And this allows replication to optionally originate from relkind 'p'
> relations on the publication server, whereas it could previously only
> originate from relkind 'r' relations.  Combined with the first item,
> users can now replicate between partitioned tables that have a
> different set of partitions on the two servers.
> 
> Maybe it would make sense to combine the three into one item:
> 
> <para>
> Add support for logical replication of partitioned tables
> </para>
> 
> <para>
> Logical replication can now occur between partitioned tables, where
> previously it would only be allowed between regular tables. A new
> publication option <literal>publish_via_partition_root</literal>
> controls whether a leaf partition's changes are published as its own
> or as that of the ancestor that's actually published.
> </para>

I think trying to put this all into one item is too complex, but I did
merge two of the items together, so we have two items now:

    <listitem>
    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
    2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
    Author: Peter Eisentraut <peter@eisentraut.org>
    2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
    -->
    
    <para>
    Allow partitioned tables to be replicated via publications (Amit Langote)
    </para>
    
    <para>
    Previously, partitions had to be replicated individually.  Now
    partitioned tables can be published explicitly causing all partitions
    to be automatically published.  Addition/removal of partitions from
    partitioned tables are automatically added/removed on subscribers.
    The CREATE PUBLICATION option publish_via_partition_root controls whether
    partitioned tables are published as themselves or their ancestors.
    </para>
    
    </listitem>
    
    <listitem>
    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
    2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
    -->
    
    <para>
    Allow non-partitioned tables to be logically replicated to subscribers
    that receive the rows into partitioned tables (Amit Langote)
    </para>
    
    </listitem>

--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 08:48:49AM -0400, Bruce Momjian wrote:
> I think trying to put this all into one item is too complex, but I did
> merge two of the items together, so we have two items now:

I ended up adjusting the wording again, so please review the commit or
the website:

    https://momjian.us/pgsql_docs/release-13.html

Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 08:29:55AM +0200, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> > > > > * "DOCUMENT THE DEFAULT GENERATION METHOD"
> > > > >   => The default is still to generate data client-side.
> > > > 
> > > > My point is that the docs are not clear about this.
> > > 
> > > Indeed.
> > > 
> > > > Can you fix it?
> > > 
> > > Sure. Attached patch adds an explicit sentence about it, as it was only
> > > hinted about in the default initialization command string, and removes a
> > > spurious empty paragraph found nearby.
> > 
> > Thanks, patch applied.
> 
> Ok.
> 
> You might remove the "DOCUMENT THE DEFAULT…" in the release note.

Oh, yes, of course.

> I'm wondering about the commit comment: "Reported-by: Fabien COELHO",
> actually you reported it, not me!

Uh, kind of, yeah, but via email, you did.  ;-)

> After looking again at the release notes, I do really think that significant
> documentation changes do not belong to the "Source code" section but should
> be in separate "Documentation" section, and that more items should be listed
> there, because they represent a lot of not-so-fun work, especially Tom's
> restructuration of tables, and possibly others.

Uh, can someone else give an opinion on this?  I am not sure how hard or
un-fun an item is should be used as criteria.

> About pgbench, ISTM that d37ddb745be07502814635585cbf935363c8a33d is worth
> mentionning because it is a user-visible change.

Uh, that is not usually something I mention because, like error message
changes, it is nice, but few people need to know about it before they
see it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May  6, 2020 at 07:31:14PM -0500, Justin Pryzby wrote:
> On Wed, May 06, 2020 at 07:35:34PM -0400, Bruce Momjian wrote:
> > On Wed, May  6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> > > I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything
pglz-compressed)decompression should be significantly faster in v13.
 
> > > https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06
> > 
> > OK, I read the thread mentioned in the commit message and I now see the
> > value of this change.  Attached is the release note diff.  Let me know
> > if it needs improvement.
> 
> Sorry I didn't see it earlier, but:
> 
> > -Improve retrieving of only the leading bytes of TOAST values (Binguo Bao)
> > +Improve speed of TOAST decompression and the retrievel of only the leading bytes of TOAST values (Binguo Bao,
AndreyBorodin)
 
> 
> retrieval
> 
> I will include this with my running doc patch if you don't want to make a
> separate commit.

Fixed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 11:25:47AM +0500, Andrey M. Borodin wrote:
> 
> 
> > 7 мая 2020 г., в 04:35, Bruce Momjian <bruce@momjian.us> написал(а):
> > 
> > On Wed, May  6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote:
> >> 
> >> 
> >>> 5 мая 2020 г., в 08:16, Bruce Momjian <bruce@momjian.us> написал(а):
> >>> 
> >>> I have committed the first draft of the PG 13 release notes.  You can
> >>> see them here:
> >>> 
> >>>     https://momjian.us/pgsql_docs/release-13.html
> >>> 
> >>> It still needs markup, word wrap, and indenting.  The community doc
> >>> build should happen in a few hours.
> >> 
> >> I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything
pglz-compressed)decompression should be significantly faster in v13.
 
> >> https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06
> > 
> > OK, I read the thread mentioned in the commit message and I now see the
> > value of this change.  Attached is the release note diff.  Let me know
> > if it needs improvement.
> 
> There is one minor typo retrievel -> retrieval.
> Thanks!

Got it, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May  6, 2020 at 10:20:57PM -0700, Noah Misch wrote:
> On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
> > On Tue, May  5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> > > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > > > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
> > > 
> > > Kyotaro Horiguchi authored that one.  (I committed it.)  The commit message
> > > noted characteristics, some of which may deserve mention in the notes:
> > 
> > Fixed.
> 
> I don't see that change pushed (but it's not urgent).

I got stuck on Amit's partition items and my head couldn't process any
more, so I went to bed, and just committed it now.  I was afraid to have
pending stuff uncommitted, but I am also hesitant to do a commit for
each change.

> > > - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
> > 
> > This was not backpatched?
> 
> Right.

Oh.  So you are saying we could lose COPY data on a crash, even after a
commit.  That seems bad.  Can you show me the commit info?  I can't find
it.

> > > - Out-of-tree table access methods will require changes.
> > 
> > Uh, I don't think we mention those.
> 
> Okay.  This point is relatively-important.  On the other hand, the table
> access methods known to me have maintainers who follow -hackers.  They may
> learn that way.

That was my thought.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May  6, 2020 at 04:01:44PM -0400, Chapman Flack wrote:
> On 05/05/20 10:31, Bruce Momjian wrote:
> > On Tue, May  5, 2020 at 09:20:39PM +0800, John Naylor wrote:
> >> ... This patch is
> >> about the server encoding, which formerly needed to be utf-8 for
> >> non-ascii characters. (I think the client encoding doesn't matter as
> >> long as ascii bytes are represented.)
> >>
> >> +<para>
> >> +The UTF-8 characters must be available in the server encoding.
> >> +</para>
> >>
> >> Same here, s/UTF-8/Unicode/.
> > 
> > OK, new text is:
> > 
> >     Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
> >     encoding (Tom Lane)
> >     
> >     The Unicode characters must be available in the server encoding.
> > 
> > I kept the "UTF-8 encoding" since that is the only Unicode encoding we
> > support.
> 
> My understanding also was that it matters little to this change what the
> /client's/ encoding is.
> 
> There used to be a limitation of the server's lexer that would reject
> Unicode escapes whenever the /server's/ encoding wasn't UTF-8 (even
> if the server's encoding contained the characters the escapes represent).
> I think that limitation is what was removed.
> 
> I don't think the client encoding comes into it at all. Sure, you could
> just include the characters literally if they are in the client encoding,
> but you might still choose to express them as escapes, and if you do they
> get passed that way to the server for interpretation.

Ah, very good point.  New text is:

    Allow Unicode escapes, e.g., E'\u####', in databases that do not
    use UTF-8 encoding (Tom Lane)

    The Unicode characters must be available in the database encoding.

> I had assumed the patch applied to all of the forms U&'\####',
> U&'\+######', E'\u####', and E'\U######' but I don't think I read
> the patch to be sure of that.

I am only using E'\u####' as an example.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> OK, I have moved her name to be first.  FYI, this commit was backpatched
> back through PG 11, though the commit message doesn't mention that.

If it was back-patched, it should not be appearing in the v13 release
notes at all, surely?

            regards, tom lane



Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> On Thu, May  7, 2020 at 08:29:55AM +0200, Fabien COELHO wrote:
>> After looking again at the release notes, I do really think that significant
>> documentation changes do not belong to the "Source code" section but should
>> be in separate "Documentation" section, and that more items should be listed
>> there, because they represent a lot of not-so-fun work, especially Tom's
>> restructuration of tables, and possibly others.

> Uh, can someone else give an opinion on this?  I am not sure how hard or
> un-fun an item is should be used as criteria.

Historically we don't document documentation changes at all, do we?
It seems (a) pointless and (b) circular.

            regards, tom lane



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 09:49:49AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > OK, I have moved her name to be first.  FYI, this commit was backpatched
> > back through PG 11, though the commit message doesn't mention that.
> 
> If it was back-patched, it should not be appearing in the v13 release
> notes at all, surely?

Well, her name was there already for a later commit that was not
backpatched, so I just moved her name earlier.  The fact that her name
was moved earlier because of something that was backpatched is
inconsistent, but I don't know enough about the work that went into the
item to comment on that.  I will need someone to tell me, of the commits
that only appear in PG 13, what should be the name order.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Amit Langote
Date:
On Thu, May 7, 2020 at 11:12 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Thu, May  7, 2020 at 09:49:49AM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > OK, I have moved her name to be first.  FYI, this commit was backpatched
> > > back through PG 11, though the commit message doesn't mention that.
> >
> > If it was back-patched, it should not be appearing in the v13 release
> > notes at all, surely?
>
> Well, her name was there already for a later commit that was not
> backpatched, so I just moved her name earlier.  The fact that her name
> was moved earlier because of something that was backpatched is
> inconsistent, but I don't know enough about the work that went into the
> item to comment on that.  I will need someone to tell me, of the commits
> that only appear in PG 13, what should be the name order.

Sorry, I misremembered that the patch to make default partition
pruning more aggressive was not backpatched, because I thought at the
time that the patch had turned somewhat complex, but indeed it was
backpatched; in 11.5 release notes:

  Prune a partitioned table's default partition (that is, avoid
uselessly scanning it) in more cases (Yuzuko Hosoya)

Sorry for the noise.

I think it's okay for her name to appear first even considering the
commits that only appear in PG 13, because my role was mainly
reviewing the work and perhaps posting an updated version of her
patch.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



Re: PG 13 release notes, first draft

From
Amit Langote
Date:
On Thu, May 7, 2020 at 9:48 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Thu, May  7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> > +Author: Etsuro Fujita <efujita@postgresql.org>
> > +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
> > +Author: Tom Lane <tgl@sss.pgh.pa.us>
> > +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
> > +-->
> > +
> > +<para>
> > +Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
> > Etsuro Fujita, Amit Langote)
> > +</para>
> >
> > Maybe it would be better to break this into two items, because while
> > c8434d64c is significant new functionality that I only contributed a
> > few review comments towards, 981643dcd is relatively minor surgery of
>
> What text would we use for the new item?  I thought FULL JOIN was just
> another case that matched the description I had.

c8434d64c implements a new feature whereby, to use partitionwise join,
partition bounds of the tables being joined no longer have to match
exactly.  I think it might be better to mention this explicitly
because it enables partitionwise joins to be used in more partitioning
setups.

981643dcd fixes things so that 3-way and higher FULL JOINs can now be
performed partitionwise.  I am okay with even omitting this if it
doesn't sound big enough to be its own item.

> I think trying to put this all into one item is too complex, but I did
> merge two of the items together, so we have two items now:
>
>         <listitem>
>         <!--
>         Author: Peter Eisentraut <peter@eisentraut.org>
>         2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
>         Author: Peter Eisentraut <peter@eisentraut.org>
>         2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
>         -->
>
>         <para>
>         Allow partitioned tables to be replicated via publications (Amit Langote)
>         </para>
>
>         <para>
>         Previously, partitions had to be replicated individually.  Now
>         partitioned tables can be published explicitly causing all partitions
>         to be automatically published.  Addition/removal of partitions from
>         partitioned tables are automatically added/removed on subscribers.
>         The CREATE PUBLICATION option publish_via_partition_root controls whether
>         partitioned tables are published as themselves or their ancestors.
>         </para>

Thanks.  Sounds good except I think the last sentence should read:

...controls whether partition changes are published as their own or as
their ancestor's.

>         </listitem>
>
>         <listitem>
>         <!--
>         Author: Peter Eisentraut <peter@eisentraut.org>
>         2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
>         -->
>
>         <para>
>         Allow non-partitioned tables to be logically replicated to subscribers
>         that receive the rows into partitioned tables (Amit Langote)
>         </para>

Hmm, why it make it sound like this works only if the source table is
non-partitioned?  The source table can be anything, a regular
non-partitioned table, or a partitioned one.

How about:

Allow logical replication into partitioned tables on subscribers

Previously, it was allowed only into regular [ non-partitioned ] tables.

--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 11:30:40PM +0900, Amit Langote wrote:
> On Thu, May 7, 2020 at 11:12 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Well, her name was there already for a later commit that was not
> > backpatched, so I just moved her name earlier.  The fact that her name
> > was moved earlier because of something that was backpatched is
> > inconsistent, but I don't know enough about the work that went into the
> > item to comment on that.  I will need someone to tell me, of the commits
> > that only appear in PG 13, what should be the name order.
> 
> Sorry, I misremembered that the patch to make default partition
> pruning more aggressive was not backpatched, because I thought at the
> time that the patch had turned somewhat complex, but indeed it was
> backpatched; in 11.5 release notes:
> 
>   Prune a partitioned table's default partition (that is, avoid
> uselessly scanning it) in more cases (Yuzuko Hosoya)
> 
> Sorry for the noise.
> 
> I think it's okay for her name to appear first even considering the
> commits that only appear in PG 13, because my role was mainly
> reviewing the work and perhaps posting an updated version of her
> patch.

OK, confirmed, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, May  8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
> On Thu, May 7, 2020 at 9:48 PM Bruce Momjian <bruce@momjian.us> wrote:
> > On Thu, May  7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> > > +Author: Etsuro Fujita <efujita@postgresql.org>
> > > +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
> > > +Author: Tom Lane <tgl@sss.pgh.pa.us>
> > > +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
> > > +-->
> > > +
> > > +<para>
> > > +Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
> > > Etsuro Fujita, Amit Langote)
> > > +</para>
> > >
> > > Maybe it would be better to break this into two items, because while
> > > c8434d64c is significant new functionality that I only contributed a
> > > few review comments towards, 981643dcd is relatively minor surgery of
> >
> > What text would we use for the new item?  I thought FULL JOIN was just
> > another case that matched the description I had.
> 
> c8434d64c implements a new feature whereby, to use partitionwise join,
> partition bounds of the tables being joined no longer have to match
> exactly.  I think it might be better to mention this explicitly
> because it enables partitionwise joins to be used in more partitioning
> setups.

Well, the text says:

    Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
    Etsuro Fujita, Amit Langote, Tom Lane)

Isn't that what you just said?  I just added this paragraph:

    For example, partitionwise joins can now happen between partitioned
    tables where the ancestors do not exactly match.

Does that help?

> 981643dcd fixes things so that 3-way and higher FULL JOINs can now be
> performed partitionwise.  I am okay with even omitting this if it
> doesn't sound big enough to be its own item.
> 
> > I think trying to put this all into one item is too complex, but I did
> > merge two of the items together, so we have two items now:
> >
> >         <listitem>
> >         <!--
> >         Author: Peter Eisentraut <peter@eisentraut.org>
> >         2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
> >         Author: Peter Eisentraut <peter@eisentraut.org>
> >         2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
> >         -->
> >
> >         <para>
> >         Allow partitioned tables to be replicated via publications (Amit Langote)
> >         </para>
> >
> >         <para>
> >         Previously, partitions had to be replicated individually.  Now
> >         partitioned tables can be published explicitly causing all partitions
> >         to be automatically published.  Addition/removal of partitions from
> >         partitioned tables are automatically added/removed on subscribers.
> >         The CREATE PUBLICATION option publish_via_partition_root controls whether
> >         partitioned tables are published as themselves or their ancestors.
> >         </para>
> 
> Thanks.  Sounds good except I think the last sentence should read:
> 
> ...controls whether partition changes are published as their own or as
> their ancestor's.

OK, done.

> >         </listitem>
> >
> >         <listitem>
> >         <!--
> >         Author: Peter Eisentraut <peter@eisentraut.org>
> >         2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
> >         -->
> >
> >         <para>
> >         Allow non-partitioned tables to be logically replicated to subscribers
> >         that receive the rows into partitioned tables (Amit Langote)
> >         </para>
> 
> Hmm, why it make it sound like this works only if the source table is
> non-partitioned?  The source table can be anything, a regular
> non-partitioned table, or a partitioned one.

Well, we already covered the publish partitioned case in the above item.

> How about:
> 
> Allow logical replication into partitioned tables on subscribers
> 
> Previously, it was allowed only into regular [ non-partitioned ] tables.

OK, I used this wording:

    Allow logical replication into partitioned tables on subscribers (Amit
    Langote)
    
    Previously, subscribers could only receive rows into non-partitioned
    tables.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Alexander Korotkov
Date:
On Thu, May 7, 2020 at 2:46 AM Bruce Momjian <bruce@momjian.us> wrote:
>         <para>
>         Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita
Glukhov)
>         </para>

Should we specify which particular opclasses are affected?  Or at
least mention it affects core and particular contribs?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



Re: PG 13 release notes, first draft

From
Chapman Flack
Date:
On 05/07/20 09:46, Bruce Momjian wrote:
> Ah, very good point.  New text is:
> 
>     Allow Unicode escapes, e.g., E'\u####', in databases that do not
>     use UTF-8 encoding (Tom Lane)
> 
>     The Unicode characters must be available in the database encoding.
> ...
> 
> I am only using E'\u####' as an example.

Hmm, how about:

    Allow Unicode escapes, e.g., E'\u####' or U&'\####', to represent
    any character available in the database encoding, even when that
    encoding is not UTF-8.

which I suggest as I recall more clearly that the former condition
was not that such escapes were always rejected in other encodings; it was
that they were rejected if they represented characters outside of ASCII.
(Yossarian let out a respectful whistle.)

My inclination is to give at least one example each of the E and U&
form, if only so the casual reader of the notes may think "say! I hadn't
heard of that other form!" and be inspired to find out about it. But
perhaps it seems too much.

Regards,
-Chap



Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
Hi Bruce,

On Mon, May 4, 2020 at 8:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html

I see that you have an entry for the deduplication feature:

"More efficiently store duplicates in btree indexes (Anastasia
Lubennikova, Peter Geoghegan)"

I would like to provide some input on this. Fortunately it's much
easier to explain than the B-Tree work that went into Postgres 12. I
think that you should point out that deduplication works by storing
the duplicates in the obvious way: Only storing the key once per
distinct value (or once per distinct combination of values in the case
of multi-column indexes), followed by an array of TIDs (i.e. a posting
list). Each TID points to a separate row in the table.

It won't be uncommon for this to make indexes as much as 3x smaller
(it depends on a number of different factors that you can probably
guess). I wrote a summary of how it works for power users in the
B-Tree documentation chapter, which you might want to link to in the
release notes:

https://www.postgresql.org/docs/devel/btree-implementation.html#BTREE-DEDUPLICATION

Users that pg_upgrade will have to REINDEX to actually use the
feature, regardless of which version they've upgraded from. There are
also some limited caveats about the data types that can use
deduplication, and stuff like that -- see the documentation section I
linked to.

Finally, you might want to note that the feature is enabled by
default, and can be disabled by setting the "deduplicate_items" index
storage option to "off". (We have yet to make a final decision on
whether the feature should be enabled before the first stable release
of Postgres 13, though -- I have an open item for that.)

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Michael Paquier
Date:
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>     https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thanks Bruce for compiling the release notes.  Here are some comments
from me, after looking at the state of the notes as of f2ff203.

Should e2e02191 be added to the notes?  This commit means that we
actually dropped support for Windows 2000 (finally) at run-time.

At the same time I see no mention of 79dfa8af, which added better
error handling when backends the SSL context with incorrect bounds.

What about fc8cb94, which basically means that vacuumlo and oid2name
are able to now support coloring output for their logging?

<para>
Document color support (Peter Eisentraut)
</para>
[...]
<para>
THIS WAS NOT DOCUMENTED BEFORE?
</para>
Not sure that there is a point to add that to the release notes.
--
Michael

Attachment

Re: PG 13 release notes, first draft

From
Amit Langote
Date:
On Fri, May 8, 2020 at 2:06 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May  8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
> > c8434d64c implements a new feature whereby, to use partitionwise join,
> > partition bounds of the tables being joined no longer have to match
> > exactly.  I think it might be better to mention this explicitly
> > because it enables partitionwise joins to be used in more partitioning
> > setups.
>
> Well, the text says:
>
>         Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
>         Etsuro Fujita, Amit Langote, Tom Lane)
>
> Isn't that what you just said?  I just added this paragraph:
>
>         For example, partitionwise joins can now happen between partitioned
>         tables where the ancestors do not exactly match.
>
> Does that help?

Yes, although "ancestors do not exactly match" doesn't make clear what
about partitioned tables doesn't match.   "partition bounds do not
exactly match" would.

> > >         <para>
> > >         Previously, partitions had to be replicated individually.  Now
> > >         partitioned tables can be published explicitly causing all partitions
> > >         to be automatically published.  Addition/removal of partitions from
> > >         partitioned tables are automatically added/removed on subscribers.
> > >         The CREATE PUBLICATION option publish_via_partition_root controls whether
> > >         partitioned tables are published as themselves or their ancestors.
> > >         </para>
> >
> > Thanks.  Sounds good except I think the last sentence should read:
> >
> > ...controls whether partition changes are published as their own or as
> > their ancestor's.
>
> OK, done.

Hmm, I see that you only took "as their own".

- ...controls whether partitioned tables are published as themselves
or their ancestors.
+ ...controls whether partitioned tables are published as their own or
their ancestors.

and that makes the new sentence sound less clear.  I mainly wanted
"partitioned table" replaced by "partition", because only then the
phrase "as their own or their ancestor's" would make sense.

I know our partitioning terminology can be very confusing with many
terms including at least "partitioned table", "partition", "ancestor",
"leaf partition", "parent", "child", etc. that I see used.

> > >         </listitem>
> > >
> > >         <listitem>
> > >         <!--
> > >         Author: Peter Eisentraut <peter@eisentraut.org>
> > >         2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
> > >         -->
> > >
> > >         <para>
> > >         Allow non-partitioned tables to be logically replicated to subscribers
> > >         that receive the rows into partitioned tables (Amit Langote)
> > >         </para>
> >
> > Hmm, why it make it sound like this works only if the source table is
> > non-partitioned?  The source table can be anything, a regular
> > non-partitioned table, or a partitioned one.
>
> Well, we already covered the publish partitioned case in the above item.
>
> > How about:
> >
> > Allow logical replication into partitioned tables on subscribers
> >
> > Previously, it was allowed only into regular [ non-partitioned ] tables.
>
> OK, I used this wording:
>
>         Allow logical replication into partitioned tables on subscribers (Amit
>         Langote)
>
>         Previously, subscribers could only receive rows into non-partitioned
>         tables.

This is fine, thanks.

I have attached a patch with my suggestions above.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com

Attachment

Re: PG 13 release notes, first draft

From
Noah Misch
Date:
On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> On Wed, May  6, 2020 at 10:20:57PM -0700, Noah Misch wrote:
> > On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
> > > On Tue, May  5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> > > > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > > > > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
> > > > 
> > > > Kyotaro Horiguchi authored that one.  (I committed it.)  The commit message
> > > > noted characteristics, some of which may deserve mention in the notes:
> > > 
> > > Fixed.
> > 
> > I don't see that change pushed (but it's not urgent).
> 
> I got stuck on Amit's partition items and my head couldn't process any
> more, so I went to bed, and just committed it now.  I was afraid to have
> pending stuff uncommitted, but I am also hesitant to do a commit for
> each change.

Got it, +1 for batching such changes.

> > > > - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
> > > 
> > > This was not backpatched?
> > 
> > Right.
> 
> Oh.  So you are saying we could lose COPY data on a crash, even after a
> commit.  That seems bad.  Can you show me the commit info?  I can't find
> it.

commit c6b9204
Author:     Noah Misch <noah@leadboat.com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit:     Noah Misch <noah@leadboat.com>
CommitDate: Sat Apr 4 12:25:34 2020 -0700

    Skip WAL for new relfilenodes, under wal_level=minimal.
    
    Until now, only selected bulk operations (e.g. COPY) did this.  If a
    given relfilenode received both a WAL-skipping COPY and a WAL-logged
    operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
    src/backend/access/transam/README section "Skipping WAL for New
    RelFileNode" for the new coding rules.  Maintainers of table access
    methods should examine that section.
    
    To maintain data durability, just before commit, we choose between an
    fsync of the relfilenode and copying its contents to WAL.  A new GUC,
    wal_skip_threshold, guides that choice.  If this change slows a workload
    that creates small, permanent relfilenodes under wal_level=minimal, try
    adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may
    need to adjust that timeout, and log_min_duration_statement analysis
    will reflect time consumption moving to COMMIT from commands like COPY.
    
    Internally, this requires a reliable determination of whether
    RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
    current relfilenode.  Introduce rd_firstRelfilenodeSubid.  Amend the
    specification of rd_createSubid such that the field is zero when a new
    rel has an old rd_node.  Make relcache.c retain entries for certain
    dropped relations until end of transaction.
    
    Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
    Future servers accept older WAL, so this bump is discretionary.
    
    Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
    Haas.  Heikki Linnakangas and Michael Paquier implemented earlier
    designs that materially clarified the problem.  Reviewed, in earlier
    designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
    Fujii Masao, and Simon Riggs.  Reported by Martijn van Oosterhout.
    
    Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org



Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Tom,

>> Uh, can someone else give an opinion on this?  I am not sure how hard or
>> un-fun an item is should be used as criteria.

> Historically we don't document documentation changes at all, do we?

ISTM that the "we did not do it previously" is as weak an argument as 
un-fun-ness:-)

> It seems (a) pointless

I disagree, on the very principle of free software values as a social 
movement.

Documentation improvements should be encouraged, and recognizing these in 
the release notes contributes to do that for what is a lot of unpaid work 
given freely by many people. I do not see this as "pointless", on the 
contrary, having something "free" in a mostly mercantile world is odd 
enough to deserve some praise.

How many hours have you spent on the function operator table improvements? 
If someone else had contributed that and only that to a release, would it 
not justify two lines of implicit thanks somewhere down in the release 
notes?

Moreover adding a documentation section costs next to nothing, so what is 
the actual point of not doing it? Also, having some documentation 
improvements listed under "source code" does not make sense: writing good, 
precise and structured English is not "source code".

> and (b) circular.

Meh. The whole documentation is "circular" by construction, with 
references from one section to the next and back, indexes, glossary, 
acronyms, tutorials, whatever.

-- 
Fabien.



Re: PG 13 release notes, first draft

From
Peter Eisentraut
Date:
On 2020-05-05 22:29, Bruce Momjian wrote:
>>>> a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517
>>>> 2fc2a88e67 Remove obsolete information schema tables
>>> Uh, that didn't seem significant.
>> Maybe have one item "modernize information_schema", and then describe
>> all the changes together in a single item.
> Uh, so I am unclear when we are adding items to information_schema
> because we now support them, and when they are new features of
> information_schema.

The addition was because it's a new SQL standard part that was published 
in the meantime.

The removals were because they no longer exist in the current standard 
version and keeping them otherwise didn't make sense.

Neither of these need to be mentioned in the release notes IMO.

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



Re: PG 13 release notes, first draft

From
Amit Kapila
Date:
On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>         https://momjian.us/pgsql_docs/release-13.html
>

Thanks for the work.  I was today going through the release notes and
was wondering whether we should consider adding information about some
other work done for PG13.
1.  We have allowed an (auto)vacuum to display additional information
about heap or index in case of an error in commit b61d161c14 [1].
Now, in general, it might not be worth saying much about error
information but I think this one could help users in case they have
some corruption.  For example, if one of the indexes on a relation has
some corrupted data (due to bad hardware or some bug), it will let the
user know the index information, and the user can take appropriate
action like either Reindex or maybe drop and recreate the index to
overcome the problem.
2. In the "Source Code" section, we can add information about
infrastructure enhancement for parallelism.  Basically, "Allow
relation extension and page lock to conflict among parallel-group
members" [2][3].  This will allow improving the parallelism further in
many cases like (a) we can allow multiple workers to operate on a heap
and index in a parallel vacuum, (b) we can allow parallel Inserts,
etc.


[1] - https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b61d161c146328ae6ba9ed937862d66e5c8b035a
[2] - https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=85f6b49c2c53fb1e08d918ec9305faac13cf7ad6
[3] - https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3ba59ccc896e8877e2fbfb8d4f148904cad5f9b0

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



Re: PG 13 release notes, first draft

From
Etsuro Fujita
Date:
On Fri, May 8, 2020 at 12:07 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Fri, May 8, 2020 at 2:06 AM Bruce Momjian <bruce@momjian.us> wrote:
> > On Fri, May  8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
> > > c8434d64c implements a new feature whereby, to use partitionwise join,
> > > partition bounds of the tables being joined no longer have to match
> > > exactly.  I think it might be better to mention this explicitly
> > > because it enables partitionwise joins to be used in more partitioning
> > > setups.
> >
> > Well, the text says:
> >
> >         Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
> >         Etsuro Fujita, Amit Langote, Tom Lane)
> >
> > Isn't that what you just said?  I just added this paragraph:
> >
> >         For example, partitionwise joins can now happen between partitioned
> >         tables where the ancestors do not exactly match.
> >
> > Does that help?
>
> Yes, although "ancestors do not exactly match" doesn't make clear what
> about partitioned tables doesn't match.   "partition bounds do not
> exactly match" would.

+1 for that change.

Thank you for taking the time to this!

Best regards,
Etsuro Fujita



Re: PG 13 release notes, first draft (ltree dot star)

From
Justin Pryzby
Date:
> In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}", properly interpret that as "*{5}" (Nikita
Glukhov)

I think that should say ".*" not "*", as in:

> In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}", properly interpret that as "*{5}" (Nikita
Glukhov)

The existing text clearly came from the commit message, which (based on its
regression tests) I think was the source of the missing dot.

commit 9950c8aadf0edd31baec74a729d47d94af636c06
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sat Mar 28 18:31:05 2020 -0400

    Fix lquery's behavior for consecutive '*' items.
    
    Something like "*{2}.*{3}" should presumably mean the same as
    "*{5}", but it didn't.  Improve that.
    ...

-- 
Justin



Re: PG 13 release notes, first draft

From
Amit Kapila
Date:
On Sat, May 9, 2020 at 11:16 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> >
>
> Thanks for the work.  I was today going through the release notes and
> was wondering whether we should consider adding information about some
> other work done for PG13.
> 1.  We have allowed an (auto)vacuum to display additional information
> about heap or index in case of an error in commit b61d161c14 [1].
> Now, in general, it might not be worth saying much about error
> information but I think this one could help users in case they have
> some corruption.  For example, if one of the indexes on a relation has
> some corrupted data (due to bad hardware or some bug), it will let the
> user know the index information, and the user can take appropriate
> action like either Reindex or maybe drop and recreate the index to
> overcome the problem.
> 2. In the "Source Code" section, we can add information about
> infrastructure enhancement for parallelism.  Basically, "Allow
> relation extension and page lock to conflict among parallel-group
> members" [2][3].  This will allow improving the parallelism further in
> many cases like (a) we can allow multiple workers to operate on a heap
> and index in a parallel vacuum, (b) we can allow parallel Inserts,
> etc.
>

One more observation:

Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
Praliaskouski)
This new behavior allows pages to be set as all-visible, which then
allows index-only scans, ...

The above sentence sounds to mean that this feature allows index-only
scans in more number of cases after this feature.  Is that what you
intend to say? If so, is that correct?  Because I think this will
allow index-only scans to skip "Heap Fetches" in more cases.

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



Re: PG 13 release notes, first draft

From
Tatsuro Yamada
Date:
Hi Bruce,

On 2020/05/05 12:16, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
> 
>     https://momjian.us/pgsql_docs/release-13.html
> 
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thanks for working on this! :-D

Could you add "Vinayak Pokale" as a co-author of the following feature since
I sometimes read his old patch to create a patch [1] ?

=======================
E.1.3.1.6. System Views

-  Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada)

+  Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada, Vinayak
Pokale)
=======================

[1]
https://www.postgresql.org/message-id/20190813140127.GA4933%40alvherre.pgsql

Thanks,
Tatsuro Yamada




Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 08:12:30PM +0300, Alexander Korotkov wrote:
> On Thu, May 7, 2020 at 2:46 AM Bruce Momjian <bruce@momjian.us> wrote:
> >         <para>
> >         Allow CREATE INDEX to specify the GiST signature length and maximum number of integer ranges (Nikita
Glukhov)
> >         </para>
> 
> Should we specify which particular opclasses are affected?  Or at
> least mention it affects core and particular contribs?

Sorry for the delay in replying.  Yes, I agree we should list all of
those operator class cases where we now take arguments.  I looked at the
patch but got confused and missed the doc changes that clearly need to
be in the release notes.  I see these operator classes now taking
parameters, as you helpfully listed in your commit message:

    tsvector_ops
    gist_ltree_ops
    gist__ltree_ops
    gist_trgm_ops
    gist_hstore_ops
    gist__int_ops
    gist__intbig_ops

I assume the double-underscore is because the first underscore is to
separate words, and the second one is for the array designation, right?

So my big question is whether people will understand when they are using
these operator classes, since many of them are defaults.  Can you use an
operator class parameter when you are just using the default operator
class and not specifying its name?  What I thinking  that just saying
the operator class take arguments might not be helpful.  I think I see
enough detail in the documentation to write release note items for
these, but I will have to point out they need to specify the operator
class, even if it is the default, right?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Alexander Korotkov
Date:
On Mon, May 11, 2020 at 4:20 PM Bruce Momjian <bruce@momjian.us> wrote:
> Sorry for the delay in replying.  Yes, I agree we should list all of
> those operator class cases where we now take arguments.  I looked at the
> patch but got confused and missed the doc changes that clearly need to
> be in the release notes.  I see these operator classes now taking
> parameters, as you helpfully listed in your commit message:
>
>         tsvector_ops
>         gist_ltree_ops
>         gist__ltree_ops
>         gist_trgm_ops
>         gist_hstore_ops
>         gist__int_ops
>         gist__intbig_ops
>
> I assume the double-underscore is because the first underscore is to
> separate words, and the second one is for the array designation, right?

Yes, this is true.

> So my big question is whether people will understand when they are using
> these operator classes, since many of them are defaults.  Can you use an
> operator class parameter when you are just using the default operator
> class and not specifying its name?

Actually no.  Initial version of patch allowed to explicitly specify
DEFAULT keyword instead of opclass name.  But I didn't like idea to
allow keyword instead of name there.

I've tried to implement syntax allowing specifying parameters without
both new keyword and opclass name, but that causes a lot of grammar
problems.

Finally, I've decided to provide parameters functionality only when
specifying opclass name.  My motivation is that opclass parameters is
functionality for advanced users, who are deeply concerned into what
opclass do.  For this category of users it's natural to know the
opclass name.

> What I thinking  that just saying
> the operator class take arguments might not be helpful.  I think I see
> enough detail in the documentation to write release note items for
> these, but I will have to point out they need to specify the operator
> class, even if it is the default, right?

My point was that we should specify where to look to find new
functionality.  We can don't write opclass names, because those names
might be confusing for users who are not aware of them.  We may
briefly say that new parameters are introduced for GiST for tsvector,
contrib/intarray, contrib/pg_trgm, contrib/ltree, contrib/hstore.
What do you think?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
Hello

> +<!--
> +Author: Alexander Korotkov <akorotkov@postgresql.org>
> +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql
> +-->
> +
> +<para>
> +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander
Korotkov)
> +</para>

I think this item should list the commands in question:
\dA, \dAc, \dAf, \dAo, \dAp
(All the other psql entries in the relnotes do that).

Thanks

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



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-11, Alvaro Herrera wrote:

> Hello
> 
> > +<!--
> > +Author: Alexander Korotkov <akorotkov@postgresql.org>
> > +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql
> > +-->
> > +
> > +<para>
> > +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander
Korotkov)
> > +</para>
> 
> I think this item should list the commands in question:
> \dA, \dAc, \dAf, \dAo, \dAp
> (All the other psql entries in the relnotes do that).

Sorry, it's the last four only -- \dA is an older command.

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



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 08:41:00PM +0300, Alexander Korotkov wrote:
> On Mon, May 11, 2020 at 4:20 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Sorry for the delay in replying.  Yes, I agree we should list all of
> > those operator class cases where we now take arguments.  I looked at the
> > patch but got confused and missed the doc changes that clearly need to
> > be in the release notes.  I see these operator classes now taking
> > parameters, as you helpfully listed in your commit message:
> >
> >         tsvector_ops
> >         gist_ltree_ops
> >         gist__ltree_ops
> >         gist_trgm_ops
> >         gist_hstore_ops
> >         gist__int_ops
> >         gist__intbig_ops
> >
> > I assume the double-underscore is because the first underscore is to
> > separate words, and the second one is for the array designation, right?
> 
> Yes, this is true.

OK.

> > So my big question is whether people will understand when they are using
> > these operator classes, since many of them are defaults.  Can you use an
> > operator class parameter when you are just using the default operator
> > class and not specifying its name?
> 
> Actually no.  Initial version of patch allowed to explicitly specify
> DEFAULT keyword instead of opclass name.  But I didn't like idea to
> allow keyword instead of name there.
> 
> I've tried to implement syntax allowing specifying parameters without
> both new keyword and opclass name, but that causes a lot of grammar
> problems.
> 
> Finally, I've decided to provide parameters functionality only when
> specifying opclass name.  My motivation is that opclass parameters is
> functionality for advanced users, who are deeply concerned into what
> opclass do.  For this category of users it's natural to know the
> opclass name.

Yes, that is good analysis, and your final decision was probably
correct.  I now see that the complexity is not a big problem.

> > What I thinking  that just saying
> > the operator class take arguments might not be helpful.  I think I see
> > enough detail in the documentation to write release note items for
> > these, but I will have to point out they need to specify the operator
> > class, even if it is the default, right?
> 
> My point was that we should specify where to look to find new
> functionality.  We can don't write opclass names, because those names
> might be confusing for users who are not aware of them.  We may
> briefly say that new parameters are introduced for GiST for tsvector,
> contrib/intarray, contrib/pg_trgm, contrib/ltree, contrib/hstore.
> What do you think?

OK, I have applied the attached patch, which I now think is the right
level of detail, given your information above.  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Attachment

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 02:08:58PM -0400, Chapman Flack wrote:
> On 05/07/20 09:46, Bruce Momjian wrote:
> > Ah, very good point.  New text is:
> > 
> >     Allow Unicode escapes, e.g., E'\u####', in databases that do not
> >     use UTF-8 encoding (Tom Lane)
> > 
> >     The Unicode characters must be available in the database encoding.
> > ...
> > 
> > I am only using E'\u####' as an example.
> 
> Hmm, how about:
> 
>     Allow Unicode escapes, e.g., E'\u####' or U&'\####', to represent
>     any character available in the database encoding, even when that
>     encoding is not UTF-8.
> 
> which I suggest as I recall more clearly that the former condition
> was not that such escapes were always rejected in other encodings; it was
> that they were rejected if they represented characters outside of ASCII.
> (Yossarian let out a respectful whistle.)

I like your wording, but the "that encoding" wasn't clear enough for me,
so I reworded it to:

    Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
    character available in the database encoding, even when the database
    encoding is not UTF-8 (Tom Lane)

> My inclination is to give at least one example each of the E and U&
> form, if only so the casual reader of the notes may think "say! I hadn't
> heard of that other form!" and be inspired to find out about it. But
> perhaps it seems too much.

Sure, works for me.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 11:54:12AM -0700, Peter Geoghegan wrote:
> Hi Bruce,
> 
> On Mon, May 4, 2020 at 8:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> 
> I see that you have an entry for the deduplication feature:
> 
> "More efficiently store duplicates in btree indexes (Anastasia
> Lubennikova, Peter Geoghegan)"
> 
> I would like to provide some input on this. Fortunately it's much
> easier to explain than the B-Tree work that went into Postgres 12. I
  -----------------

Well, that's good!  :-)

> think that you should point out that deduplication works by storing
> the duplicates in the obvious way: Only storing the key once per
> distinct value (or once per distinct combination of values in the case
> of multi-column indexes), followed by an array of TIDs (i.e. a posting
> list). Each TID points to a separate row in the table.

These are not details that should be in the release notes since the
internal representation is not important for its use.

> It won't be uncommon for this to make indexes as much as 3x smaller
> (it depends on a number of different factors that you can probably
> guess). I wrote a summary of how it works for power users in the
> B-Tree documentation chapter, which you might want to link to in the
> release notes:
> 
> https://www.postgresql.org/docs/devel/btree-implementation.html#BTREE-DEDUPLICATION
> 
> Users that pg_upgrade will have to REINDEX to actually use the
> feature, regardless of which version they've upgraded from. There are
> also some limited caveats about the data types that can use
> deduplication, and stuff like that -- see the documentation section I
> linked to.

I have added text to this about pg_upgrade:

    Users upgrading with pg_upgrade will need to use REINDEX to make
    use of this feature.

> Finally, you might want to note that the feature is enabled by
> default, and can be disabled by setting the "deduplicate_items" index
> storage option to "off". (We have yet to make a final decision on
> whether the feature should be enabled before the first stable release
> of Postgres 13, though -- I have an open item for that.)

Well, again, I don't think the average user needs to know this can be
disabled.  They can look at the docs of this feature to see that.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, May  8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
> On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> > 
> >     https://momjian.us/pgsql_docs/release-13.html
> > 
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Thanks Bruce for compiling the release notes.  Here are some comments
> from me, after looking at the state of the notes as of f2ff203.
> 
> Should e2e02191 be added to the notes?  This commit means that we
> actually dropped support for Windows 2000 (finally) at run-time.

Oh, yes.  This is much more important than the removal of support for
non-ELF BSD systems, which I already listed.  The new text is:

    Remove support for Windows 2000 (Michael Paquier)

> At the same time I see no mention of 79dfa8af, which added better
> error handling when backends the SSL context with incorrect bounds.

I skipped that commit since people don't normally care about better
error messages until they see the error message, and then they are happy
it is there, unless this is some chronic error message problem we are
fixing.

> What about fc8cb94, which basically means that vacuumlo and oid2name
> are able to now support coloring output for their logging?

I thought this fell into the previous category about error messages, but
coloring is different.  Can we say these utilities now honor the color
environment variables?  Are these the only new ones?

> <para>
> Document color support (Peter Eisentraut)
> </para>
> [...]
> <para>
> THIS WAS NOT DOCUMENTED BEFORE?
> </para>
> Not sure that there is a point to add that to the release notes.

OK, removed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, May  8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > OK, I used this wording:
> >
> >         Allow logical replication into partitioned tables on subscribers (Amit
> >         Langote)
> >
> >         Previously, subscribers could only receive rows into non-partitioned
> >         tables.
> 
> This is fine, thanks.
> 
> I have attached a patch with my suggestions above.

OK, I slightly modified the wording of your first change, patch
attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Attachment

Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Mon, May 11, 2020 at 4:10 PM Bruce Momjian <bruce@momjian.us> wrote:
> > think that you should point out that deduplication works by storing
> > the duplicates in the obvious way: Only storing the key once per
> > distinct value (or once per distinct combination of values in the case
> > of multi-column indexes), followed by an array of TIDs (i.e. a posting
> > list). Each TID points to a separate row in the table.
>
> These are not details that should be in the release notes since the
> internal representation is not important for its use.

I am not concerned about describing the specifics of the on-disk
representation, and I don't feel too strongly about the storage
parameter (leave it out). I only ask that the wording convey the fact
that the deduplication feature is not just a quantitative improvement
-- it's a qualitative behavioral change, that will help data
warehousing in particular. This wasn't the case with the v12 work on
B-Tree duplicates (as I said last year, I thought of the v12 stuff as
fixing a problem more than an enhancement).

With the deduplication feature added to Postgres v13, the B-Tree code
can now gracefully deal with low cardinality data by compressing the
duplicates as needed. This is comparable to bitmap indexes in
proprietary database systems, but without most of their disadvantages
(in particular around heavyweight locking, deadlocks that abort
transactions, etc). It's easy to imagine this making a big difference
with analytics workloads. The v12 work made indexes with lots of
duplicates 15%-30% smaller (compared to v11), but the v13 work can
make them 60% - 80% smaller in many common cases (compared to v12). In
extreme cases indexes might even be ~12x smaller (though that will be
rare).

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May  7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
> > > > 
> > > > This was not backpatched?
> > > 
> > > Right.
> > 
> > Oh.  So you are saying we could lose COPY data on a crash, even after a
> > commit.  That seems bad.  Can you show me the commit info?  I can't find
> > it.
> 
> commit c6b9204
> Author:     Noah Misch <noah@leadboat.com>
> AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> Commit:     Noah Misch <noah@leadboat.com>
> CommitDate: Sat Apr 4 12:25:34 2020 -0700
> 
>     Skip WAL for new relfilenodes, under wal_level=minimal.
>     
>     Until now, only selected bulk operations (e.g. COPY) did this.  If a
>     given relfilenode received both a WAL-skipping COPY and a WAL-logged
>     operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
>     src/backend/access/transam/README section "Skipping WAL for New
>     RelFileNode" for the new coding rules.  Maintainers of table access
>     methods should examine that section.

OK, so how do we want to document this?  Do I mention in the text below
the WAL skipping item that this fixes a bug where a mix of simultaneous
COPY and INSERT into a table could lose rows during crash recovery, or
create a new item?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 05:05:29PM -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2020 at 4:10 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > think that you should point out that deduplication works by storing
> > > the duplicates in the obvious way: Only storing the key once per
> > > distinct value (or once per distinct combination of values in the case
> > > of multi-column indexes), followed by an array of TIDs (i.e. a posting
> > > list). Each TID points to a separate row in the table.
> >
> > These are not details that should be in the release notes since the
> > internal representation is not important for its use.
> 
> I am not concerned about describing the specifics of the on-disk
> representation, and I don't feel too strongly about the storage
> parameter (leave it out). I only ask that the wording convey the fact
> that the deduplication feature is not just a quantitative improvement
> -- it's a qualitative behavioral change, that will help data
> warehousing in particular. This wasn't the case with the v12 work on
> B-Tree duplicates (as I said last year, I thought of the v12 stuff as
> fixing a problem more than an enhancement).
> 
> With the deduplication feature added to Postgres v13, the B-Tree code
> can now gracefully deal with low cardinality data by compressing the
> duplicates as needed. This is comparable to bitmap indexes in
> proprietary database systems, but without most of their disadvantages
> (in particular around heavyweight locking, deadlocks that abort
> transactions, etc). It's easy to imagine this making a big difference
> with analytics workloads. The v12 work made indexes with lots of
> duplicates 15%-30% smaller (compared to v11), but the v13 work can
> make them 60% - 80% smaller in many common cases (compared to v12). In
> extreme cases indexes might even be ~12x smaller (though that will be
> rare).

Agreed.  How is this?

    This allows efficient btree indexing of low cardinality columns.
    Users upgrading with pg_upgrade will need to use REINDEX to make use of
    this feature.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, May  8, 2020 at 09:14:01AM +0200, Fabien COELHO wrote:
> > It seems (a) pointless
> 
> I disagree, on the very principle of free software values as a social
> movement.
> 
> Documentation improvements should be encouraged, and recognizing these in
> the release notes contributes to do that for what is a lot of unpaid work
> given freely by many people. I do not see this as "pointless", on the
> contrary, having something "free" in a mostly mercantile world is odd enough
> to deserve some praise.
> 
> How many hours have you spent on the function operator table improvements?
> If someone else had contributed that and only that to a release, would it
> not justify two lines of implicit thanks somewhere down in the release
> notes?
> 
> Moreover adding a documentation section costs next to nothing, so what is
> the actual point of not doing it? Also, having some documentation
> improvements listed under "source code" does not make sense: writing good,
> precise and structured English is not "source code".

We have long discussed how much of the release notes is to reward
behavior, and we have settled on having the names on the items, and the
Acknowledgments section at the bottom.  If you want to revisit that
decision, you should start a new thread because doing it for just this
item doesn't make sense.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Sat, May  9, 2020 at 11:16:27AM +0530, Amit Kapila wrote:
> On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> >
> 
> Thanks for the work.  I was today going through the release notes and
> was wondering whether we should consider adding information about some
> other work done for PG13.
> 1.  We have allowed an (auto)vacuum to display additional information
> about heap or index in case of an error in commit b61d161c14 [1].
> Now, in general, it might not be worth saying much about error
> information but I think this one could help users in case they have
> some corruption.  For example, if one of the indexes on a relation has
> some corrupted data (due to bad hardware or some bug), it will let the
> user know the index information, and the user can take appropriate
> action like either Reindex or maybe drop and recreate the index to
> overcome the problem.

I mentioned my approach to error message changes in a previous email
today:

    I skipped that commit since people don't normally care about
    better error messages until they see the error message, and then
    they are happy it is there, unless this is some chronic error
    message problem we are fixing.

> 2. In the "Source Code" section, we can add information about
> infrastructure enhancement for parallelism.  Basically, "Allow
> relation extension and page lock to conflict among parallel-group
> members" [2][3].  This will allow improving the parallelism further in
> many cases like (a) we can allow multiple workers to operate on a heap
> and index in a parallel vacuum, (b) we can allow parallel Inserts,
> etc.

Uh, if there is no user-visible behavior change, this seems too low
level for the release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> One more observation:
> 
> Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> Praliaskouski)
> This new behavior allows pages to be set as all-visible, which then
> allows index-only scans, ...
> 
> The above sentence sounds to mean that this feature allows index-only
> scans in more number of cases after this feature.  Is that what you
> intend to say? If so, is that correct?  Because I think this will

Yes.

> allow index-only scans to skip "Heap Fetches" in more cases.

Uh, by definition an index-only scan only scans the index, not the heap,
right?  It is true there are fewer heap fetches, but fewer heap features
I thought mean more index-only scans.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft (ltree dot star)

From
Bruce Momjian
Date:
On Sun, May 10, 2020 at 03:09:47PM -0500, Justin Pryzby wrote:
> > In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}", properly interpret that as "*{5}" (Nikita
Glukhov)
> 
> I think that should say ".*" not "*", as in:
> 
> > In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}", properly interpret that as "*{5}" (Nikita
Glukhov)
> 
> The existing text clearly came from the commit message, which (based on its
> regression tests) I think was the source of the missing dot.
> 
> commit 9950c8aadf0edd31baec74a729d47d94af636c06
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Date:   Sat Mar 28 18:31:05 2020 -0400
> 
>     Fix lquery's behavior for consecutive '*' items.
>     
>     Something like "*{2}.*{3}" should presumably mean the same as
>     "*{5}", but it didn't.  Improve that.
>     ...

OK, fixed to be:

    In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}",
    properly interpret that as ".*{5}" (Nikita Glukhov)

I added two dots.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce@momjian.us> wrote:
> Agreed.  How is this?
>
>         This allows efficient btree indexing of low cardinality columns.
>         Users upgrading with pg_upgrade will need to use REINDEX to make use of
>         this feature.

I still think that the release notes should say that the key is only
stored once, while TIDs that identify table rows are stored together
as an array. Everything that's helpful (or harmful) about the feature
happens as a consequence of that. This isn't hard to grasp
intuitively, and is totally in line with how things like Oracle bitmap
indexes are presented to ordinary users.

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 03:19:50PM +0900, Tatsuro Yamada wrote:
> Hi Bruce,
> 
> On 2020/05/05 12:16, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> > 
> >     https://momjian.us/pgsql_docs/release-13.html
> > 
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Thanks for working on this! :-D
> 
> Could you add "Vinayak Pokale" as a co-author of the following feature since
> I sometimes read his old patch to create a patch [1] ?
> 
> =======================
> E.1.3.1.6. System Views
> 
> -  Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada)
> 
> +  Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada, Vinayak
Pokale)
> =======================

Done.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-11, Bruce Momjian wrote:

> We have long discussed how much of the release notes is to reward
> behavior, and we have settled on having the names on the items, and the
> Acknowledgments section at the bottom.

Yes, we had to touch the source code in order to add documentation; but
so what?  Everything touches the source code, but that doesn't mean it
should be listed there.  I don't see what's the problem with having a
new subsection in the relnotes entitled "Documentation" where these two
items appears (glossary + new doc table format) are listed.  It's not
like it's going to cost us a lot of space or anything.

I don't think there is any circularity argument BTW -- we're not going
to document that we added release notes.  And changing the table format
is not entirely pointless, given that we've historically had trouble
with these tables (read: they're totally unusable in PDF).

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



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
|Allow function call backtraces of errors to be logged (Peter Eisentraut, Álvaro Herrera)
|Server variable backtrace_functions specifies which C functions should generate backtraces on error.

I think the details in the description are eclipsing the most important thing:
backtraces on Assert().  I would say "Support for showing backtraces on error".

Regarding this one:
|Add system view pg_shmem_allocations to display shared memory usage (Andres Freund, Robert Haas)
|WHAT IS THE ENTRY WITH NO NAME?

There seems to be two special, "unnamed" cases:
src/backend/storage/ipc/shmem.c-        /* output shared memory allocated but not counted via the shmem index */
src/backend/storage/ipc/shmem.c:        values[0] = CStringGetTextDatum("<anonymous>");
...
src/backend/storage/ipc/shmem.c-        /* output as-of-yet unused shared memory */
src/backend/storage/ipc/shmem.c-        nulls[0] = true;

That seems to be adequately documented:
https://www.postgresql.org/docs/devel/view-pg-shmem-allocations.html
|NULL for unused memory and <anonymous> for anonymous allocations.

I would remove this part:
"Previously, this could only be set at server start."

-- 
Justin



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > 1.  We have allowed an (auto)vacuum to display additional information
> > about heap or index in case of an error in commit b61d161c14 [1].
> > Now, in general, it might not be worth saying much about error
> > information but I think this one could help users in case they have
> > some corruption.  For example, if one of the indexes on a relation has
> > some corrupted data (due to bad hardware or some bug), it will let the
> > user know the index information, and the user can take appropriate
> > action like either Reindex or maybe drop and recreate the index to
> > overcome the problem.

I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption.  If we were to include more "error" items,
we might also include these:

71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
17a28b03645e27d73bf69a95d7569b61e58f06eb Improve the internal implementation of ereport().
05f18c6b6b6e4b44302ee20a042cedc664532aa2 Added relation name in error messages for constraint checks.
33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e Add object names to partition integrity violations.

> One more observation:
> 
> Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> Praliaskouski)
> This new behavior allows pages to be set as all-visible, which then
> allows index-only scans, ...

> The above sentence sounds to mean that this feature allows index-only
> scans in more number of cases after this feature.  Is that what you
> intend to say? If so, is that correct?  Because I think this will
> allow index-only scans to skip "Heap Fetches" in more cases.

I think what you mean is that the autovacuum feature, in addition to
encouraging the *planner* to choose an indexonly scan, will *also* allow (at
execution time) fewer heap fetches for a plan which would have
already/previously used IOS.  Right ?  So maybe it should say "allows OR
IMPROVES index-only scans" or "allows plans which use IOS to run more
efficiently".

Separate from Amit's comment, I suggest to say:
| This new behavior allows autovacuum to set pages as all-visible, which then
| allows index-only scans, ...

..otherwise it sounds like this feature implemented the concept of
"all-visible".

-- 
Justin



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 04:50:50PM -0400, Alvaro Herrera wrote:
> Hello
> 
> > +<!--
> > +Author: Alexander Korotkov <akorotkov@postgresql.org>
> > +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql
> > +-->
> > +
> > +<para>
> > +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander
Korotkov)
> > +</para>
> 
> I think this item should list the commands in question:
> \dA, \dAc, \dAf, \dAo, \dAp
> (All the other psql entries in the relnotes do that).

Good idea.  I added this paragraph:

    The new commands are \dAc, \dAf, \dAo, and \dAp.

I didn't see any changes to \dA except regression tests.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
> On 2020-May-11, Bruce Momjian wrote:
> 
> > We have long discussed how much of the release notes is to reward
> > behavior, and we have settled on having the names on the items, and the
> > Acknowledgments section at the bottom.
> 
> Yes, we had to touch the source code in order to add documentation; but
> so what?  Everything touches the source code, but that doesn't mean it
> should be listed there.  I don't see what's the problem with having a
> new subsection in the relnotes entitled "Documentation" where these two
> items appears (glossary + new doc table format) are listed.  It's not
> like it's going to cost us a lot of space or anything.
> 
> I don't think there is any circularity argument BTW -- we're not going
> to document that we added release notes.  And changing the table format
> is not entirely pointless, given that we've historically had trouble
> with these tables (read: they're totally unusable in PDF).

Well, are you suggesting a new section because the glossary shouldn't be
listed under source code, or because you want the function reformatting
added?  We just need to understand what the purpose is.  We already have
the glossary listed, since that is new and user-visible.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > One more observation:
> > 
> > Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> > Praliaskouski)
> > This new behavior allows pages to be set as all-visible, which then
> > allows index-only scans, ...
> 
> > The above sentence sounds to mean that this feature allows index-only
> > scans in more number of cases after this feature.  Is that what you
> > intend to say? If so, is that correct?  Because I think this will
> > allow index-only scans to skip "Heap Fetches" in more cases.
> 
> I think what you mean is that the autovacuum feature, in addition to
> encouraging the *planner* to choose an indexonly scan, will *also* allow (at
> execution time) fewer heap fetches for a plan which would have
> already/previously used IOS.  Right ?  So maybe it should say "allows OR
> IMPROVES index-only scans" or "allows plans which use IOS to run more
> efficiently".

Yes, I see your point now.  New text is:

    This new behavior reduces the work necessary when the table
    needs to be frozen and allows pages to be set as all-visible.
    All-visible pages allow index-only scans to access fewer heap rows.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 05:09:54PM -0400, Alvaro Herrera wrote:
> On 2020-May-11, Alvaro Herrera wrote:
> 
> > Hello
> > 
> > > +<!--
> > > +Author: Alexander Korotkov <akorotkov@postgresql.org>
> > > +2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql
> > > +-->
> > > +
> > > +<para>
> > > +Add psql commands to report operator classes and operator families (Sergey Cherkashin, Nikita Glukhov, Alexander
Korotkov)
> > > +</para>
> > 
> > I think this item should list the commands in question:
> > \dA, \dAc, \dAf, \dAo, \dAp
> > (All the other psql entries in the relnotes do that).
> 
> Sorry, it's the last four only -- \dA is an older command.

OK, confirmed, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 07:41:01PM -0500, Justin Pryzby wrote:
> |Allow function call backtraces of errors to be logged (Peter Eisentraut, Álvaro Herrera)
> |Server variable backtrace_functions specifies which C functions should generate backtraces on error.
> 
> I think the details in the description are eclipsing the most important thing:
> backtraces on Assert().  I would say "Support for showing backtraces on error".

Uh, you mean this adds backtraces for errors and asserts?  Are
non-developers running assert builds?

> Regarding this one:
> |Add system view pg_shmem_allocations to display shared memory usage (Andres Freund, Robert Haas)
> |WHAT IS THE ENTRY WITH NO NAME?
> 
> There seems to be two special, "unnamed" cases:
> src/backend/storage/ipc/shmem.c-        /* output shared memory allocated but not counted via the shmem index */
> src/backend/storage/ipc/shmem.c:        values[0] = CStringGetTextDatum("<anonymous>");
> ...
> src/backend/storage/ipc/shmem.c-        /* output as-of-yet unused shared memory */
> src/backend/storage/ipc/shmem.c-        nulls[0] = true;
> 
> That seems to be adequately documented:
> https://www.postgresql.org/docs/devel/view-pg-shmem-allocations.html
> |NULL for unused memory and <anonymous> for anonymous allocations.

OK, thanks.  Comment removed.

> I would remove this part:
> "Previously, this could only be set at server start."

OK, you rae saying it is already clear, agreed, removed.


-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Agreed.  How is this?
> >
> >         This allows efficient btree indexing of low cardinality columns.
> >         Users upgrading with pg_upgrade will need to use REINDEX to make use of
> >         this feature.
> 
> I still think that the release notes should say that the key is only
> stored once, while TIDs that identify table rows are stored together
> as an array. Everything that's helpful (or harmful) about the feature
> happens as a consequence of that. This isn't hard to grasp
> intuitively, and is totally in line with how things like Oracle bitmap
> indexes are presented to ordinary users.

I still don't think these details belong in the release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 09:15:43PM -0400, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> > On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > Agreed.  How is this?
> > >
> > >         This allows efficient btree indexing of low cardinality columns.
> > >         Users upgrading with pg_upgrade will need to use REINDEX to make use of
> > >         this feature.
> > 
> > I still think that the release notes should say that the key is only
> > stored once, while TIDs that identify table rows are stored together
> > as an array. Everything that's helpful (or harmful) about the feature
> > happens as a consequence of that. This isn't hard to grasp
> > intuitively, and is totally in line with how things like Oracle bitmap
> > indexes are presented to ordinary users.
> 
> I still don't think these details belong in the release notes.

OK, I was able to add some of it cleanly:

    This allows efficient btree indexing of low cardinality columns by
    storing duplicate keys only once.  Users upgrading with pg_upgrade
    will need to use REINDEX to make use of this feature.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Amit Langote
Date:
On Tue, May 12, 2020 at 8:51 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May  8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > I have attached a patch with my suggestions above.
>
> OK, I slightly modified the wording of your first change, patch
> attached.

Thanks.  I checked that what you committed looks fine.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Mon, May 11, 2020 at 6:23 PM Bruce Momjian <bruce@momjian.us> wrote:
> OK, I was able to add some of it cleanly:
>
>         This allows efficient btree indexing of low cardinality columns by
>         storing duplicate keys only once.  Users upgrading with pg_upgrade
>         will need to use REINDEX to make use of this feature.

That seems like a reasonable compromise. Thanks!

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Michael Paquier
Date:
On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
> On Fri, May  8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
>> Should e2e02191 be added to the notes?  This commit means that we
>> actually dropped support for Windows 2000 (finally) at run-time.
>
> Oh, yes.  This is much more important than the removal of support for
> non-ELF BSD systems, which I already listed.  The new text is:
>
>     Remove support for Windows 2000 (Michael Paquier)

Sounds fine to me.

>> At the same time I see no mention of 79dfa8af, which added better
>> error handling when backends the SSL context with incorrect bounds.
>
> I skipped that commit since people don't normally care about better
> error messages until they see the error message, and then they are happy
> it is there, unless this is some chronic error message problem we are
> fixing.

Okay.

> I thought this fell into the previous category about error messages, but
> coloring is different.  Can we say these utilities now honor the color
> environment variables?

Exactly, I actually became aware of that possibility after plugging
in the common logging APIs to oid2name and vacuumlo as of fc8cb94b so
this was not mentioned in the log message.  And anything using
src/common/logging.c can make use of the colorized output with
PG_COLOR[S] set.

> Are these the only new ones?

I can recall an extra one in this case: pgbench as of 30a3e77.  And I
don't see any new callers of pg_logging_init() in the stuff that
already existed in ~12.
--
Michael

Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> I like your wording, but the "that encoding" wasn't clear enough for me,
> so I reworded it to:

>     Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
>     character available in the database encoding, even when the database
>     encoding is not UTF-8 (Tom Lane)

How about "to be used for" instead of "to represent"?  "Represent" kind
of sounds like we're using these on output, which we aren't.

            regards, tom lane



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-11, Bruce Momjian wrote:

> On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:

> > Yes, we had to touch the source code in order to add documentation; but
> > so what?  Everything touches the source code, but that doesn't mean it
> > should be listed there.  I don't see what's the problem with having a
> > new subsection in the relnotes entitled "Documentation" where these two
> > items appears (glossary + new doc table format) are listed.  It's not
> > like it's going to cost us a lot of space or anything.

> Well, are you suggesting a new section because the glossary shouldn't be
> listed under source code, or because you want the function reformatting
> added?  We just need to understand what the purpose is.  We already have
> the glossary listed, since that is new and user-visible.

IMO the table reformatting change is significant enough to be
noteworthy.  I'm suggesting that a new Documentation subsection would
list both that and the glossary, separately from Source Code -- so it'd
be E.1.3.10 and Source Code would be E.1.3.11.

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



Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> Well, are you suggesting a new section because the glossary shouldn't be
> listed under source code, or because you want the function reformatting
> added?  We just need to understand what the purpose is.  We already have
> the glossary listed, since that is new and user-visible.

The implication of what you say here is that "is it user-visible?"
is a criterion for whether to release-note something.  By that logic
we probably *should* relnote the function table layout changes, because
they sure as heck are user-visible.  People might or might not notice
addition of a glossary, but I think just about every user consults
the function/operator tables regularly.

I concur with Alvaro's position that if we are listing documentation
changes, pushing them under "Source Code" is not the way to do it.
That subsection has always been understood to be "stuff you don't
care about if you're not a hacker".

So that sort of leads me to the conclusion that "major documentation
changes" might be a reasonable sub-heading for the release notes.

            regards, tom lane



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May 12, 2020 at 10:54:52AM +0900, Michael Paquier wrote:
> On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
> > On Fri, May  8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
> >> Should e2e02191 be added to the notes?  This commit means that we
> >> actually dropped support for Windows 2000 (finally) at run-time.
> > 
> > Oh, yes.  This is much more important than the removal of support for
> > non-ELF BSD systems, which I already listed.  The new text is:
> > 
> >     Remove support for Windows 2000 (Michael Paquier)
> 
> Sounds fine to me.
> 
> >> At the same time I see no mention of 79dfa8af, which added better
> >> error handling when backends the SSL context with incorrect bounds.
> > 
> > I skipped that commit since people don't normally care about better
> > error messages until they see the error message, and then they are happy
> > it is there, unless this is some chronic error message problem we are
> > fixing.
> 
> Okay.
> 
> > I thought this fell into the previous category about error messages, but
> > coloring is different.  Can we say these utilities now honor the color
> > environment variables?
> 
> Exactly, I actually became aware of that possibility after plugging
> in the common logging APIs to oid2name and vacuumlo as of fc8cb94b so
> this was not mentioned in the log message.  And anything using
> src/common/logging.c can make use of the colorized output with
> PG_COLOR[S] set.
> 
> > Are these the only new ones?
> 
> I can recall an extra one in this case: pgbench as of 30a3e77.  And I
> don't see any new callers of pg_logging_init() in the stuff that
> already existed in ~12.

I am not sure we even mentioned this in 12.  Should we document this
somewhere?  Maybe a blog posting?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I like your wording, but the "that encoding" wasn't clear enough for me,
> > so I reworded it to:
> 
> >     Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
> >     character available in the database encoding, even when the database
> >     encoding is not UTF-8 (Tom Lane)
> 
> How about "to be used for" instead of "to represent"?  "Represent" kind
> of sounds like we're using these on output, which we aren't.

Uh, I think "used for" is worse though, since we are not using it.  I
don't get the "output" feel of the word at all.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Amit Kapila
Date:
On Tue, May 12, 2020 at 6:36 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
> > On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > One more observation:
> > >
> > > Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> > > Praliaskouski)
> > > This new behavior allows pages to be set as all-visible, which then
> > > allows index-only scans, ...
> >
> > > The above sentence sounds to mean that this feature allows index-only
> > > scans in more number of cases after this feature.  Is that what you
> > > intend to say? If so, is that correct?  Because I think this will
> > > allow index-only scans to skip "Heap Fetches" in more cases.
> >
> > I think what you mean is that the autovacuum feature, in addition to
> > encouraging the *planner* to choose an indexonly scan, will *also* allow (at
> > execution time) fewer heap fetches for a plan which would have
> > already/previously used IOS.  Right ?  So maybe it should say "allows OR
> > IMPROVES index-only scans" or "allows plans which use IOS to run more
> > efficiently".
>
> Yes, I see your point now.  New text is:
>
>         This new behavior reduces the work necessary when the table
>         needs to be frozen and allows pages to be set as all-visible.
>         All-visible pages allow index-only scans to access fewer heap rows.
>

The next text LGTM.  Thanks.

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



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 10:23:53PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Well, are you suggesting a new section because the glossary shouldn't be
> > listed under source code, or because you want the function reformatting
> > added?  We just need to understand what the purpose is.  We already have
> > the glossary listed, since that is new and user-visible.
> 
> The implication of what you say here is that "is it user-visible?"
> is a criterion for whether to release-note something.  By that logic
> we probably *should* relnote the function table layout changes, because
> they sure as heck are user-visible.  People might or might not notice
> addition of a glossary, but I think just about every user consults
> the function/operator tables regularly.
> 
> I concur with Alvaro's position that if we are listing documentation
> changes, pushing them under "Source Code" is not the way to do it.
> That subsection has always been understood to be "stuff you don't
> care about if you're not a hacker".
> 
> So that sort of leads me to the conclusion that "major documentation
> changes" might be a reasonable sub-heading for the release notes.

OK, section and item added, patch attached,

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Attachment

Re: PG 13 release notes, first draft

From
Tatsuro Yamada
Date:
On 2020/05/12 9:34, Bruce Momjian wrote:
>> Could you add "Vinayak Pokale" as a co-author of the following feature since
>> I sometimes read his old patch to create a patch [1] ?
>>
>> =======================
>> E.1.3.1.6. System Views
>>
>> -  Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada)
>>
>> +  Add system view pg_stat_progress_analyze to report analyze progress (Álvaro Herrera, Tatsuro Yamada, Vinayak
Pokale)
>> =======================
> 
> Done.


Hi Bruce,

Thank you!


Regards,
Tatsuro Yamada







Re: PG 13 release notes, first draft

From
Amit Kapila
Date:
On Tue, May 12, 2020 at 6:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > 1.  We have allowed an (auto)vacuum to display additional information
> > > about heap or index in case of an error in commit b61d161c14 [1].
> > > Now, in general, it might not be worth saying much about error
> > > information but I think this one could help users in case they have
> > > some corruption.  For example, if one of the indexes on a relation has
> > > some corrupted data (due to bad hardware or some bug), it will let the
> > > user know the index information, and the user can take appropriate
> > > action like either Reindex or maybe drop and recreate the index to
> > > overcome the problem.
>
> I'm not opposed to including it, but I think it's still true that the user
> doesn't need to know in advance that the error message will be additionally
> helpful in the event of corruption.  If we were to include more "error" items,
> we might also include these:
>
> 71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
> 17a28b03645e27d73bf69a95d7569b61e58f06eb Improve the internal implementation of ereport().
> 05f18c6b6b6e4b44302ee20a042cedc664532aa2 Added relation name in error messages for constraint checks.
> 33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e Add object names to partition integrity violations.
>

I think the first one (Add backtrace support for error reporting)
seems to be quite useful as it can help to detect the problems faster.
I think having a simple rule as Bruce has w.r.t "error messages" makes
it easier to decide whether to take a particular commit or not but I
feel some of these could help users to know the new functionality and
might encourage them to upgrade to the new version.  Sure, nobody is
going to move due to only these features but along with other things,
improved error handling is a good thing to know.

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



Re: PG 13 release notes, first draft

From
Chapman Flack
Date:
On 05/11/20 22:48, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>>     Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
>>>     character available in the database encoding, even when the database
>>>     encoding is not UTF-8 (Tom Lane)
>>
>> How about "to be used for" instead of "to represent"?  "Represent" kind
>> of sounds like we're using these on output, which we aren't.
> 
> Uh, I think "used for" is worse though, since we are not using it.  I
> don't get the "output" feel of the word at all.

'specify' ?

-Chap



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> On 05/11/20 22:48, Bruce Momjian wrote:
> > On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >>>     Allow Unicode escapes, e.g., E'\u####', U&'\####', to represent any
> >>>     character available in the database encoding, even when the database
> >>>     encoding is not UTF-8 (Tom Lane)
> >>
> >> How about "to be used for" instead of "to represent"?  "Represent" kind
> >> of sounds like we're using these on output, which we aren't.
> > 
> > Uh, I think "used for" is worse though, since we are not using it.  I
> > don't get the "output" feel of the word at all.
> 
> 'specify' ?

I like that word if Tom prefers it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
>> 'specify' ?

> I like that word if Tom prefers it.

'specify' works for me.

            regards, tom lane



Re: PG 13 release notes, first draft

From
Kyotaro Horiguchi
Date:
At Mon, 11 May 2020 20:12:04 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Thu, May  7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> > On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > > - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
> > > > > 
> > > > > This was not backpatched?
> > > > 
> > > > Right.
> > > 
> > > Oh.  So you are saying we could lose COPY data on a crash, even after a
> > > commit.  That seems bad.  Can you show me the commit info?  I can't find
> > > it.
> > 
> > commit c6b9204
> > Author:     Noah Misch <noah@leadboat.com>
> > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > Commit:     Noah Misch <noah@leadboat.com>
> > CommitDate: Sat Apr 4 12:25:34 2020 -0700
> > 
> >     Skip WAL for new relfilenodes, under wal_level=minimal.
> >     
> >     Until now, only selected bulk operations (e.g. COPY) did this.  If a
> >     given relfilenode received both a WAL-skipping COPY and a WAL-logged
> >     operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
> >     src/backend/access/transam/README section "Skipping WAL for New
> >     RelFileNode" for the new coding rules.  Maintainers of table access
> >     methods should examine that section.
> 
> OK, so how do we want to document this?  Do I mention in the text below
> the WAL skipping item that this fixes a bug where a mix of simultaneous
> COPY and INSERT into a table could lose rows during crash recovery, or
> create a new item?

FWIW, as dicussed upthread, I suppose that the API change is not going
to be in relnotes.

something like this?

- Fix bug of WAL-skipping optimiazation 

Previously a trasaction doing both of COPY and a WAL-logged operations
like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
through crash recovery.  Also this fix extends the WAL-skipping
optimiazation to all kinds of bulk insert operations.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Bruce,

> OK, section and item added, patch attached,

Thanks!

Some items that might be considered for the added documentation section:

  * e1ff780485
  * 34a0a81bfb
  * e829337d42

  * "Document color support (Peter Eisentraut)"
    THIS WAS NOT DOCUMENTED BEFORE?

Not as such, AFAICR it was vaguely hinted about in the documentation of 
command that would use it, but not even all of them. Now there is a new 
specific section.

-- 
Fabien!



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-May-07, Bruce Momjian wrote:

> OK, I have moved her name to be first.  FYI, this commit was backpatched
> back through PG 11, though the commit message doesn't mention that.

At some point I became an avid user of our src/tools/git_changelog, and
then it stopped making sense for me to highlight in the commit message
the fact that the commit is back-patched, since it's so obvious there.
Maybe that's wrong and I should get back in the habit of mentioning it.

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



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 11, 2020 at 11:38:33PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> >> 'specify' ?
> 
> > I like that word if Tom prefers it.
> 
> 'specify' works for me.

Sure, done.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > commit c6b9204
> > > Author:     Noah Misch <noah@leadboat.com>
> > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > Commit:     Noah Misch <noah@leadboat.com>
> > > CommitDate: Sat Apr 4 12:25:34 2020 -0700
> > > 
> > >     Skip WAL for new relfilenodes, under wal_level=minimal.
> > >     
> > >     Until now, only selected bulk operations (e.g. COPY) did this.  If a
> > >     given relfilenode received both a WAL-skipping COPY and a WAL-logged
> > >     operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
> > >     src/backend/access/transam/README section "Skipping WAL for New
> > >     RelFileNode" for the new coding rules.  Maintainers of table access
> > >     methods should examine that section.
> > 
> > OK, so how do we want to document this?  Do I mention in the text below
> > the WAL skipping item that this fixes a bug where a mix of simultaneous
> > COPY and INSERT into a table could lose rows during crash recovery, or
> > create a new item?
> 
> FWIW, as dicussed upthread, I suppose that the API change is not going
> to be in relnotes.
> 
> something like this?
> 
> - Fix bug of WAL-skipping optimiazation 
> 
> Previously a trasaction doing both of COPY and a WAL-logged operations
> like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
> through crash recovery.  Also this fix extends the WAL-skipping
> optimiazation to all kinds of bulk insert operations.

Uh, that kind of mixes the bug fix and the feature in a way that it is
hard to understand.  How about this?

    Allow skipping of WAL for new tables and indexes if wal_level is
    'minimal' (Kyotaro Horiguchi)

    Relations larger than wal_skip_threshold will have their files
    fsync'ed rather than writing their WAL records.  Previously this
    was done only for COPY operations, but the implementation had a
    bug that could cause data loss during crash recovery.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May 12, 2020 at 09:43:10AM +0200, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> > OK, section and item added, patch attached,
> 
> Thanks!
> 
> Some items that might be considered for the added documentation section:
> 
>  * e1ff780485

I was told in this email thread to not include that one.

>  * 34a0a81bfb

We already have:

    Reformat tables containing function information for better
    clarity (Tom Lane)

so it seems it is covered as part of this.

>  * e829337d42

Uh, this is a doc link formatting addition.  I think this falls into the
error message logic, where it is nice when people want it, but they
don't need to know about it ahead of time.

>  * "Document color support (Peter Eisentraut)"
>    THIS WAS NOT DOCUMENTED BEFORE?
> 
> Not as such, AFAICR it was vaguely hinted about in the documentation of
> command that would use it, but not even all of them. Now there is a new
> specific section.

Again, this is the first hash you gave.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Tue, May 12, 2020 at 01:47:38PM -0400, Alvaro Herrera wrote:
> On 2020-May-07, Bruce Momjian wrote:
> 
> > OK, I have moved her name to be first.  FYI, this commit was backpatched
> > back through PG 11, though the commit message doesn't mention that.
> 
> At some point I became an avid user of our src/tools/git_changelog, and
> then it stopped making sense for me to highlight in the commit message
> the fact that the commit is back-patched, since it's so obvious there.
> Maybe that's wrong and I should get back in the habit of mentioning it.

Uh, not sure.  I don't need it since, as you said,
src/tools/git_changelog covers it, but someone got confused since they
looked at just the commit message without looking at
src/tools/git_changelog.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Kyotaro Horiguchi
Date:
At Tue, 12 May 2020 16:38:09 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > > commit c6b9204
> > > > Author:     Noah Misch <noah@leadboat.com>
> > > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > > Commit:     Noah Misch <noah@leadboat.com>
> > > > CommitDate: Sat Apr 4 12:25:34 2020 -0700
> > > > 
> > > >     Skip WAL for new relfilenodes, under wal_level=minimal.
> > > >     
> > > >     Until now, only selected bulk operations (e.g. COPY) did this.  If a
> > > >     given relfilenode received both a WAL-skipping COPY and a WAL-logged
> > > >     operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
> > > >     src/backend/access/transam/README section "Skipping WAL for New
> > > >     RelFileNode" for the new coding rules.  Maintainers of table access
> > > >     methods should examine that section.
> > > 
> > > OK, so how do we want to document this?  Do I mention in the text below
> > > the WAL skipping item that this fixes a bug where a mix of simultaneous
> > > COPY and INSERT into a table could lose rows during crash recovery, or
> > > create a new item?
> > 
> > FWIW, as dicussed upthread, I suppose that the API change is not going
> > to be in relnotes.
> > 
> > something like this?
> > 
> > - Fix bug of WAL-skipping optimiazation 
> > 
> > Previously a trasaction doing both of COPY and a WAL-logged operations
> > like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
> > through crash recovery.  Also this fix extends the WAL-skipping
> > optimiazation to all kinds of bulk insert operations.
> 
> Uh, that kind of mixes the bug fix and the feature in a way that it is
> hard to understand.  How about this?
> 
>     Allow skipping of WAL for new tables and indexes if wal_level is
>     'minimal' (Kyotaro Horiguchi)
> 
>     Relations larger than wal_skip_threshold will have their files
>     fsync'ed rather than writing their WAL records.  Previously this
>     was done only for COPY operations, but the implementation had a
>     bug that could cause data loss during crash recovery.

I see it. It is giving weight on improvement. Looks good the overall
structure of the description above.  However, wal-skipping is always
done regardless of table size. wal_skip_threshold is an optimization
to choose which to use fsync or FPI records (that is, not WAL records
in the common sense) at commit for speed.

So how about the following?

All kinds of bulk-insertion are not WAL-logged then fsync'ed at
commit.  Using FPI WAL records instead of fsync for relations smaller
than wal_skip_threshold. Previously this was done only for COPY
operations and always using fsync, but the implementation had a bug
that could cause data loss during crash recovery.


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Bruce,

>>  * e1ff780485
>
> I was told in this email thread to not include that one.

Ok.

>>  * 34a0a81bfb
>
> We already have:
>
>     Reformat tables containing function information for better
>     clarity (Tom Lane)
>
> so it seems it is covered as part of this.

AFAICR this one is not by the same author, and although the point was 
about better clarity, it was not about formating but rather about 
restructuring text vs binary string function documentations. Then Tom 
reformatted the result.

>>  * e829337d42
>
> Uh, this is a doc link formatting addition.  I think this falls into the
> error message logic, where it is nice when people want it, but they
> don't need to know about it ahead of time.

Hmmm. ISTM that this is not really about "error message logic", it is 
about navigating to libpq functions when one is reference in the 
description of another to check what it does, which I had to do a lot 
while developing some performance testing code for a project.

>>  * "Document color support (Peter Eisentraut)"
>>    THIS WAS NOT DOCUMENTED BEFORE?
>>
>> Not as such, AFAICR it was vaguely hinted about in the documentation of
>> command that would use it, but not even all of them. Now there is a new
>> specific section.
>
> Again, this is the first hash you gave.

Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to 
still be in the release notes, I gathered that the information had not 
reached its destination, hence the possible repetition. But maybe the 
issue is that this answer is not satisfactory. Sorry for the 
inconvenience.

-- 
Fabien.



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > 
> >     Allow skipping of WAL for new tables and indexes if wal_level is
> >     'minimal' (Kyotaro Horiguchi)
> > 
> >     Relations larger than wal_skip_threshold will have their files
> >     fsync'ed rather than writing their WAL records.  Previously this
> >     was done only for COPY operations, but the implementation had a
> >     bug that could cause data loss during crash recovery.
> 
> I see it. It is giving weight on improvement. Looks good the overall
> structure of the description above.  However, wal-skipping is always
> done regardless of table size. wal_skip_threshold is an optimization
> to choose which to use fsync or FPI records (that is, not WAL records
> in the common sense) at commit for speed.

Well, as far as users are concerned, everything wrtiten to  WAL is a WAL
record.

> So how about the following?
> 
> All kinds of bulk-insertion are not WAL-logged then fsync'ed at
> commit.  Using FPI WAL records instead of fsync for relations smaller
> than wal_skip_threshold. Previously this was done only for COPY
> operations and always using fsync, but the implementation had a bug
> that could cause data loss during crash recovery.

That is too much detail for the release notes.  We already will link to
the docs.  Why put it here?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, May 13, 2020 at 07:18:38AM +0200, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> > >  * e1ff780485
> > 
> > I was told in this email thread to not include that one.
> 
> Ok.
> 
> > >  * 34a0a81bfb
> > 
> > We already have:
> > 
> >     Reformat tables containing function information for better
> >     clarity (Tom Lane)
> > 
> > so it seems it is covered as part of this.
> 
> AFAICR this one is not by the same author, and although the point was about
> better clarity, it was not about formating but rather about restructuring
> text vs binary string function documentations. Then Tom reformatted the
> result.

Well, we were not even clear we should document changes in the functions
section, so going into details of all the changes seems unwise.

> > >  * e829337d42
> > 
> > Uh, this is a doc link formatting addition.  I think this falls into the
> > error message logic, where it is nice when people want it, but they
> > don't need to know about it ahead of time.
> 
> Hmmm. ISTM that this is not really about "error message logic", it is about
> navigating to libpq functions when one is reference in the description of
> another to check what it does, which I had to do a lot while developing some
> performance testing code for a project.

I don't see it.

> > >  * "Document color support (Peter Eisentraut)"
> > >    THIS WAS NOT DOCUMENTED BEFORE?
> > > 
> > > Not as such, AFAICR it was vaguely hinted about in the documentation of
> > > command that would use it, but not even all of them. Now there is a new
> > > specific section.
> > 
> > Again, this is the first hash you gave.
> 
> Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
> still be in the release notes, I gathered that the information had not
> reached its destination, hence the possible repetition. But maybe the issue
> is that this answer is not satisfactory. Sorry for the inconvenience.

I removed it already based on feedback from someone else.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Kyotaro Horiguchi
Date:
At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > > 
> > >     Allow skipping of WAL for new tables and indexes if wal_level is
> > >     'minimal' (Kyotaro Horiguchi)
> > > 
> > >     Relations larger than wal_skip_threshold will have their files
> > >     fsync'ed rather than writing their WAL records.  Previously this
> > >     was done only for COPY operations, but the implementation had a
> > >     bug that could cause data loss during crash recovery.
> > 
> > I see it. It is giving weight on improvement. Looks good the overall
> > structure of the description above.  However, wal-skipping is always
> > done regardless of table size. wal_skip_threshold is an optimization
> > to choose which to use fsync or FPI records (that is, not WAL records
> > in the common sense) at commit for speed.
> 
> Well, as far as users are concerned, everything wrtiten to  WAL is a WAL
> record.

I think that the significant point here is not that persistence is
ensured by which of fsync or WAL , but whether WAL records are written
for every insertion.  The commit-time WA is just an alternative of
fsync, which is faster than fsync'ing separate files for smaller
files.

> > So how about the following?
> > 
> > All kinds of bulk-insertion are not WAL-logged then fsync'ed at
> > commit.  Using FPI WAL records instead of fsync for relations smaller
> > than wal_skip_threshold. Previously this was done only for COPY
> > operations and always using fsync, but the implementation had a bug
> > that could cause data loss during crash recovery.
> 
> That is too much detail for the release notes.  We already will link to
> the docs.  Why put it here?

It is just an more accurate (not an detailed) version of the
previously proposed description.  If we simplify that, I choose to
remove explanation on wal_skip_threshold.

How about this?

WAL-logging is now skipped while all kinds of bulk-insertion, then
relations are sync'ed to disk at commit.  Previously this was done
only for COPY operations, but the implementation had a bug that could
cause data loss during crash recovery.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> It is just an more accurate (not an detailed) version of the
> previously proposed description.  If we simplify that, I choose to
> remove explanation on wal_skip_threshold.
> 
> How about this?
> 
> WAL-logging is now skipped while all kinds of bulk-insertion, then
> relations are sync'ed to disk at commit.  Previously this was done
> only for COPY operations, but the implementation had a bug that could
> cause data loss during crash recovery.

OK, I went with this text, stating WAL "generation" is skipped:

    Allow skipping of WAL for full table writes if wal_level is 'minimal'
    (Kyotaro Horiguchi)
    
    Relations larger than wal_skip_threshold will have their files
    fsync'ed rather than generating WAL.  Previously this was done
    only for COPY operations, but the implementation had a bug that
    could cause data loss during crash recovery.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Fabien COELHO
Date:
Hello Bruce,

>>>>  * 34a0a81bfb
>>>
>>> We already have:
>>>
>>>     Reformat tables containing function information for better
>>>     clarity (Tom Lane)
>>>
>>> so it seems it is covered as part of this.
>>
>> AFAICR this one is not by the same author, and although the point was about
>> better clarity, it was not about formating but rather about restructuring
>> text vs binary string function documentations. Then Tom reformatted the
>> result.
>
> Well, we were not even clear we should document changes in the functions
> section, so going into details of all the changes seems unwise.

The restructuring was a significant change, and ISTM that another function 
of the release note is also to implicitely thank contributors (their name 
is appended, which does not bring any useful information about the feature 
from a release note perspective) hence my suggestion to include this one,
the author of which is not Tom Lane.

>>>>  * e829337d42
>>>
>>> Uh, this is a doc link formatting addition.  I think this falls into the
>>> error message logic, where it is nice when people want it, but they
>>> don't need to know about it ahead of time.
>>
>> [...]
>
> I don't see it.

While reading again the sequence, ISTM that I did not understand your 
first answer, so my answer was kind-of off topic, sorry. This is indeed 
"link formatting addition", which helps making the libpq doc more usable.

Probably you do not need to know about it in advance, but I do not think 
that it is a good reason not to include it: with the same argument, a 
performance improvement would not need to be advertise, you'll see it when 
you need it. The same holds for all non-functional improvements, and there 
are many which are listed.

>> Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
>> still be in the release notes, I gathered that the information had not
>> reached its destination, hence the possible repetition. But maybe the issue
>> is that this answer is not satisfactory. Sorry for the inconvenience.
>
> I removed it already based on feedback from someone else.

Good. I looked at the online version which is off the latest commits by a 
few hours.

I'd consider moving "Upgrade to use DocBook 4.5 (Peter Eisentraut)" to the 
doc section, maybe.

-- 
Fabien.



Re: PG 13 release notes, first draft

From
Kyotaro Horiguchi
Date:
At Wed, 13 May 2020 22:40:52 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > It is just an more accurate (not an detailed) version of the
> > previously proposed description.  If we simplify that, I choose to
> > remove explanation on wal_skip_threshold.
> > 
> > How about this?
> > 
> > WAL-logging is now skipped while all kinds of bulk-insertion, then
> > relations are sync'ed to disk at commit.  Previously this was done
> > only for COPY operations, but the implementation had a bug that could
> > cause data loss during crash recovery.
> 
> OK, I went with this text, stating WAL "generation" is skipped:
> 
>     Allow skipping of WAL for full table writes if wal_level is 'minimal'
>     (Kyotaro Horiguchi)
>     
>     Relations larger than wal_skip_threshold will have their files
>     fsync'ed rather than generating WAL.  Previously this was done
>     only for COPY operations, but the implementation had a bug that
>     could cause data loss during crash recovery.

Although I can't help feeling it out-of-point a bit, it is right in
apperarance.  So, I don't object it.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Thu, May 14, 2020 at 07:23:05AM +0200, Fabien COELHO wrote:
> 
> Hello Bruce,
> 
> > > > >  * 34a0a81bfb
> > > > 
> > > > We already have:
> > > > 
> > > >     Reformat tables containing function information for better
> > > >     clarity (Tom Lane)
> > > > 
> > > > so it seems it is covered as part of this.
> > > 
> > > AFAICR this one is not by the same author, and although the point was about
> > > better clarity, it was not about formating but rather about restructuring
> > > text vs binary string function documentations. Then Tom reformatted the
> > > result.
> > 
> > Well, we were not even clear we should document changes in the functions
> > section, so going into details of all the changes seems unwise.
> 
> The restructuring was a significant change, and ISTM that another function
> of the release note is also to implicitely thank contributors (their name is
> appended, which does not bring any useful information about the feature from
> a release note perspective) hence my suggestion to include this one,
> the author of which is not Tom Lane.

We list people's names next to items.  We don't list items to list
people's names, as far as I know of the policy.  If you want to change
that, you will need to start a new thread and get agreement.

> > > > >  * e829337d42
> > > > 
> > > > Uh, this is a doc link formatting addition.  I think this falls into the
> > > > error message logic, where it is nice when people want it, but they
> > > > don't need to know about it ahead of time.
> > > 
> > > [...]
> > 
> > I don't see it.
> 
> While reading again the sequence, ISTM that I did not understand your first
> answer, so my answer was kind-of off topic, sorry. This is indeed "link
> formatting addition", which helps making the libpq doc more usable.

> Probably you do not need to know about it in advance, but I do not think
> that it is a good reason not to include it: with the same argument, a
> performance improvement would not need to be advertise, you'll see it when
> you need it. The same holds for all non-functional improvements, and there
> are many which are listed.

Peformance items are listed only if they will produce a visible change
in performance, or enable new workloads that were too slow in the past.

> > > Possibly, but as the "THIS WAS NOT DOCUMENTED BEFORE?" question seemed to
> > > still be in the release notes, I gathered that the information had not
> > > reached its destination, hence the possible repetition. But maybe the issue
> > > is that this answer is not satisfactory. Sorry for the inconvenience.
> > 
> > I removed it already based on feedback from someone else.
> 
> Good. I looked at the online version which is off the latest commits by a
> few hours.
> 
> I'd consider moving "Upgrade to use DocBook 4.5 (Peter Eisentraut)" to the
> doc section, maybe.

Agreed, done.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Peter Eisentraut
Date:
On 2020-05-12 02:41, Justin Pryzby wrote:
> I'm not opposed to including it, but I think it's still true that the user
> doesn't need to know in advance that the error message will be additionally
> helpful in the event of corruption.  If we were to include more "error" items,
> we might also include these:
> 
> 71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting

This is actually a legitimate user-visible feature and should be listed 
somewhere.

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



Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Thu, May 14, 2020 at 2:02 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of corruption.  If we were to include more "error" items,
> > we might also include these:
> >
> > 71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
>
> This is actually a legitimate user-visible feature and should be listed
> somewhere.

+1 -- it's very handy. Plus it has user-facing knobs.

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Justin Pryzby
Date:
On Thu, May 14, 2020 at 11:01:51PM +0200, Peter Eisentraut wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of corruption.  If we were to include more "error" items,
> > we might also include these:
> > 
> > 71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
> 
> This is actually a legitimate user-visible feature and should be listed
> somewhere.

On Thu, May 14, 2020 at 02:02:52PM -0700, Peter Geoghegan wrote:
> +1 -- it's very handy. Plus it has user-facing knobs.

That's already included:

| Allow function call backtraces of errors to be logged (Peter Eisentraut, Álvaro Herrera)
| Server variable backtrace_functions specifies which C functions should generate backtraces on error.

I 1) I failed to double check my list; and, 2) intended for that to be
interpretted as items which could be moved to a separate "error reporting"
section of the release notes.

-- 
Justin



Re: PG 13 release notes, first draft

From
Fujii Masao
Date:

On 2020/05/05 12:16, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
> 
>     https://momjian.us/pgsql_docs/release-13.html
> 
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Many thanks for working on this!

When I did "make html", I got the following message.

     Link element has no content and no Endterm. Nothing to show in the link to sepgsql

"Allow <link linkend="sepgsql"/> to control access to the" in release-13.sgml
seems to have caused this. Also I found it's converted into "Allow ??? to
  control access to the", i.e., ??? was used.

-     Allow <link linkend="sepgsql"/> to control access to the
+     Allow <link linkend="sepgsql">sepgsql</link> to control access to the

Shouldn't we change that as the above?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
> 
> 
> On 2020/05/05 12:16, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> > 
> >     https://momjian.us/pgsql_docs/release-13.html
> > 
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Many thanks for working on this!
> 
> When I did "make html", I got the following message.
> 
>     Link element has no content and no Endterm. Nothing to show in the link to sepgsql
> 
> "Allow <link linkend="sepgsql"/> to control access to the" in release-13.sgml
> seems to have caused this. Also I found it's converted into "Allow ??? to
>  control access to the", i.e., ??? was used.
> 
> -     Allow <link linkend="sepgsql"/> to control access to the
> +     Allow <link linkend="sepgsql">sepgsql</link> to control access to the
> 
> Shouldn't we change that as the above?

Actually, it should be:

    <xref linkend="sepgsql"/>

because we are using the text from the link.  See
doc/src/sgml/README.links for details on xref links.  Release notes
updated.   Odd I got no warning for this on 'make check'.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Fujii Masao
Date:

On 2020/05/15 21:29, Bruce Momjian wrote:
> On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
>>
>>
>> On 2020/05/05 12:16, Bruce Momjian wrote:
>>> I have committed the first draft of the PG 13 release notes.  You can
>>> see them here:
>>>
>>>     https://momjian.us/pgsql_docs/release-13.html
>>>
>>> It still needs markup, word wrap, and indenting.  The community doc
>>> build should happen in a few hours.
>>
>> Many thanks for working on this!
>>
>> When I did "make html", I got the following message.
>>
>>      Link element has no content and no Endterm. Nothing to show in the link to sepgsql
>>
>> "Allow <link linkend="sepgsql"/> to control access to the" in release-13.sgml
>> seems to have caused this. Also I found it's converted into "Allow ??? to
>>   control access to the", i.e., ??? was used.
>>
>> -     Allow <link linkend="sepgsql"/> to control access to the
>> +     Allow <link linkend="sepgsql">sepgsql</link> to control access to the
>>
>> Shouldn't we change that as the above?
> 
> Actually, it should be:
> 
>     <xref linkend="sepgsql"/>
> 
> because we are using the text from the link.

Yes, this works.

> See
> doc/src/sgml/README.links for details on xref links.  Release notes
> updated.

Thanks!

>   Odd I got no warning for this on 'make check'. 

I'm not sure why, but btw I got the message when I compiled the document on Mac.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, May 15, 2020 at 09:54:55PM +0900, Fujii Masao wrote:
> > Actually, it should be:
> > 
> >     <xref linkend="sepgsql"/>
> > 
> > because we are using the text from the link.
> 
> Yes, this works.
> 
> > See
> > doc/src/sgml/README.links for details on xref links.  Release notes
> > updated.
> 
> Thanks!
> 
> >   Odd I got no warning for this on 'make check'.
> 
> I'm not sure why, but btw I got the message when I compiled the document on Mac.

I don't think I looked at the HTML build output, only the check one, so
that might be the cause.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Daniel Gustafsson
Date:
> On 5 May 2020, at 05:16, Bruce Momjian <bruce@momjian.us> wrote:
> 
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:

Spotted a typo we probably should fix: s/PostgresSQL/PostgreSQL/ =)

cheers ./daniel


Attachment

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
Thanks, applied.

---------------------------------------------------------------------------

On Mon, May 18, 2020 at 11:18:51AM +0200, Daniel Gustafsson wrote:
> > On 5 May 2020, at 05:16, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> 
> Spotted a typo we probably should fix: s/PostgresSQL/PostgreSQL/ =)
> 
> cheers ./daniel
> 

> diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
> index c39a6ad38e..7f864da162 100644
> --- a/doc/src/sgml/release-13.sgml
> +++ b/doc/src/sgml/release-13.sgml
> @@ -215,7 +215,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
>  
>       <para>
>        Remove support for defining <link linkend="sql-createopclass">operator
> -      classes</link> using pre-<productname>PostgresSQL</productname>
> +      classes</link> using pre-<productname>PostgreSQL</productname>
>        8.0 syntax (Daniel Gustafsson)
>       </para>
>      </listitem>
> @@ -228,7 +228,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
>  
>       <para>
>        Remove support for defining <link linkend="sql-altertable">foreign key
> -      constraints</link> using pre-<productname>PostgresSQL</productname>
> +      constraints</link> using pre-<productname>PostgreSQL</productname>
>        7.3 syntax (Daniel Gustafsson)
>       </para>
>      </listitem>
> @@ -242,7 +242,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
>       <para>
>        Remove support for "opaque" <link
>        linkend="sql-createtype">pseudo-types</link> used by
> -      pre-<productname>PostgresSQL</productname> 7.3 servers (Daniel
> +      pre-<productname>PostgreSQL</productname> 7.3 servers (Daniel
>        Gustafsson)
>       </para>
>      </listitem>


-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Daniel Gustafsson
Date:
Spotted this in the release notes:

      <para>
       Add extension <application>bool_plperl</application> which transforms
       <acronym>SQL</acronym> booleans to/from PL/Perl booleans (Ivan
       Panchenko) WHERE IS THIS DOCUMENTED?
      </para>

bool_plperl is documented in "44.1.  PL/Perl Functions and Arguments", but not
with a separate section (which fwiw I don't disagree with).  Linking there from
the release notes entry would require some rewriting to make it fit; I would
just remove the placeholder question for this one.

cheers ./daniel


Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, May 25, 2020 at 10:54:03AM +0200, Daniel Gustafsson wrote:
> Spotted this in the release notes:
> 
>       <para>
>        Add extension <application>bool_plperl</application> which transforms
>        <acronym>SQL</acronym> booleans to/from PL/Perl booleans (Ivan
>        Panchenko) WHERE IS THIS DOCUMENTED?
>       </para>
> 
> bool_plperl is documented in "44.1.  PL/Perl Functions and Arguments", but not
> with a separate section (which fwiw I don't disagree with).  Linking there from
> the release notes entry would require some rewriting to make it fit; I would
> just remove the placeholder question for this one.

Thanks, done.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



Re: PG 13 release notes, first draft

From
Masahiko Sawada
Date:
Hi,

I realized that PG 13 release note still has the following entry:

<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
-->

      <para>
       Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
       if appropriate (Luis Carril)
      </para>

      <para>
       WHAT IS THIS ABOUT?
      </para>
     </listitem>

    </itemizedlist>

IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
command. Please find the attached patch.

Regards,

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

Attachment

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote:
> Hi,
> 
> I realized that PG 13 release note still has the following entry:
> 
> <!--
> Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> 2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
> -->
> 
>       <para>
>        Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
>        if appropriate (Luis Carril)
>       </para>
> 
>       <para>
>        WHAT IS THIS ABOUT?
>       </para>
>      </listitem>
> 
>     </itemizedlist>
> 
> IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
> command. Please find the attached patch.

OK, so if that is, what used to happen before?  Did it still work
without the FOREIGN keyword?  If so, I am thinking we should just remove
this item.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
On 2020-Jun-26, Bruce Momjian wrote:

> On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote:

> > Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> > 2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if appropriate
> > -->
> > 
> >       <para>
> >        Add <literal>FOREIGN</literal> to <command>ALTER</command> statements,
> >        if appropriate (Luis Carril)
> >       </para>

> > IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
> > command. Please find the attached patch.
> 
> OK, so if that is, what used to happen before?  Did it still work
> without the FOREIGN keyword?  If so, I am thinking we should just remove
> this item.

I tend to agree, it's not a change significant enough to be documented
in the relnotes, i think.

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



Re: PG 13 release notes, first draft

From
Alvaro Herrera
Date:
Reading Luis Carril's other entry in the relnotes,

 Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis Carril)

It seems to suggest that --include-foreign-data existed previously,
which is not true. I would have worded it as "Add --include-foreign-data
option to pg_dump to allow dumping data from foreign servers".

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



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Fri, Jun 26, 2020 at 04:23:26PM -0400, Alvaro Herrera wrote:
> Reading Luis Carril's other entry in the relnotes,
> 
>  Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis Carril)
> 
> It seems to suggest that --include-foreign-data existed previously,
> which is not true. I would have worded it as "Add --include-foreign-data
> option to pg_dump to allow dumping data from foreign servers".

OK, pg_dump item about FOREIGN keyword removed from PG 13 release notes,
and the above item clarified.   Patch attached and applied to PG 13.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee


Attachment

Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
Hi Bruce,

On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian <bruce@momjian.us> wrote:
> Patch attached and applied to PG 13.

I committed the hash_mem_multiplier GUC to Postgres 13 just now.

There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash aggregation
to use disk storage for large aggregation result sets" feature should
reference the new GUC directly. Users should be advised that the GUC
may be useful in cases where they upgrade and experience a performance
regression linked to slower hash aggregation. Just including a
documentation link for the GUC would be very helpful.

Thanks
-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, Jul 29, 2020 at 03:34:22PM -0700, Peter Geoghegan wrote:
> Hi Bruce,
> 
> On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Patch attached and applied to PG 13.
> 
> I committed the hash_mem_multiplier GUC to Postgres 13 just now.
> 
> There should be a note about this in the Postgres 13 release notes,
> for the usual reasons. More importantly, the "Allow hash aggregation
> to use disk storage for large aggregation result sets" feature should
> reference the new GUC directly. Users should be advised that the GUC
> may be useful in cases where they upgrade and experience a performance
> regression linked to slower hash aggregation. Just including a
> documentation link for the GUC would be very helpful.

I came up with the attached patch.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee


Attachment

Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
> > There should be a note about this in the Postgres 13 release notes,
> > for the usual reasons. More importantly, the "Allow hash aggregation
> > to use disk storage for large aggregation result sets" feature should
> > reference the new GUC directly. Users should be advised that the GUC
> > may be useful in cases where they upgrade and experience a performance
> > regression linked to slower hash aggregation. Just including a
> > documentation link for the GUC would be very helpful.
>
> I came up with the attached patch.

I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):

If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, Jul 29, 2020 at 07:00:43PM -0700, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons. More importantly, the "Allow hash aggregation
> > > to use disk storage for large aggregation result sets" feature should
> > > reference the new GUC directly. Users should be advised that the GUC
> > > may be useful in cases where they upgrade and experience a performance
> > > regression linked to slower hash aggregation. Just including a
> > > documentation link for the GUC would be very helpful.
> >
> > I came up with the attached patch.
> 
> I was thinking something along like the following (after the existing
> sentence about avoiding hash aggs in the planner):
> 
> If you find that hash aggregation is slower than in previous major
> releases of PostgreSQL, it may be useful to increase the value of
> hash_mem_multiplier. This allows hash aggregation to use more memory
> without affecting competing query operations that are generally less
> likely to put any additional memory to good use.

Well, that seems to be repeating what is already in the docs for
hash_mem_multiplier, which I try to avoid.  One other direction is to
put something in the incompatibilities section.  Does that make sense?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Wed, Jul 29, 2020 at 7:48 PM Bruce Momjian <bruce@momjian.us> wrote:
> Well, that seems to be repeating what is already in the docs for
> hash_mem_multiplier, which I try to avoid.  One other direction is to
> put something in the incompatibilities section.  Does that make sense?

I would prefer to put it next to the hash agg item itself. It's more
likely to be noticed there, and highlighting it a little seems
warranted.

OTOH, this may not be a problem at all for many individual users.
Framing it as a tip rather than a compatibility item gets that across.

-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
"David G. Johnston"
Date:
On Wednesday, July 29, 2020, Peter Geoghegan <pg@bowt.ie> wrote:
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
> > There should be a note about this in the Postgres 13 release notes,
> > for the usual reasons. More importantly, the "Allow hash aggregation
> > to use disk storage for large aggregation result sets" feature should
> > reference the new GUC directly. Users should be advised that the GUC
> > may be useful in cases where they upgrade and experience a performance
> > regression linked to slower hash aggregation. Just including a
> > documentation link for the GUC would be very helpful.
>
> I came up with the attached patch.

I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):

If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.


How about adding wording for GROUP BY as well to cater to users who are more comfortable thinking in terms of SQL statements instead of execution plans?

David J.

Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Wed, Jul 29, 2020 at 08:43:24PM -0700, David G. Johnston wrote:
> On Wednesday, July 29, 2020, Peter Geoghegan <pg@bowt.ie> wrote:
> 
>     On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
>     > > There should be a note about this in the Postgres 13 release notes,
>     > > for the usual reasons. More importantly, the "Allow hash aggregation
>     > > to use disk storage for large aggregation result sets" feature should
>     > > reference the new GUC directly. Users should be advised that the GUC
>     > > may be useful in cases where they upgrade and experience a performance
>     > > regression linked to slower hash aggregation. Just including a
>     > > documentation link for the GUC would be very helpful.
>     >
>     > I came up with the attached patch.
> 
>     I was thinking something along like the following (after the existing
>     sentence about avoiding hash aggs in the planner):
> 
>     If you find that hash aggregation is slower than in previous major
>     releases of PostgreSQL, it may be useful to increase the value of
>     hash_mem_multiplier. This allows hash aggregation to use more memory
>     without affecting competing query operations that are generally less
>     likely to put any additional memory to good use.

I came up with a more verbose documentation suggestion, attached.

> How about adding wording for GROUP BY as well to cater to users who are more
> comfortable thinking in terms of SQL statements instead of execution plans?

Uh, it is unclear exactly what SQL generates what node types, so I want
to avoid this.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee


Attachment

Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian <bruce@momjian.us> wrote:
> I came up with a more verbose documentation suggestion, attached.

I'm okay with this.

Thanks
-- 
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
> On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I came up with a more verbose documentation suggestion, attached.
>
> I'm okay with this.

Are you going to push this soon, Bruce?

--
Peter Geoghegan



Re: PG 13 release notes, first draft

From
Bruce Momjian
Date:
On Mon, Aug  3, 2020 at 11:35:50AM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
> > On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian <bruce@momjian.us> wrote:
> > > I came up with a more verbose documentation suggestion, attached.
> >
> > I'm okay with this.
> 
> Are you going to push this soon, Bruce?

Done.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




Re: PG 13 release notes, first draft

From
Amit Langote
Date:
On Tue, May 12, 2020 at 10:28 AM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Tue, May 12, 2020 at 8:51 AM Bruce Momjian <bruce@momjian.us> wrote:
> > On Fri, May  8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > > I have attached a patch with my suggestions above.
> >
> > OK, I slightly modified the wording of your first change, patch
> > attached.
>
> Thanks.  I checked that what you committed looks fine.

Sorry about not having reported this earlier, but I had noticed that
the wording of the partitioned tables logical replication item isn't
correct grammatically, which I noticed again while going through the
webpage.  Attached fixes it as follows:

-        to be automatically published.  Addition/removal of partitions from
-        partitioned tables are automatically added/removed from publications.
+        to be automatically published.  Adding/removing partitions from
+        a partitioned table automatically adds/removes them from publications.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com

Attachment

Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
Hi,

On 5/4/20 11:16 PM, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes.  You can
> see them here:
>
>     https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting.  The community doc
> build should happen in a few hours.

Thank you again for compiling and maintaining the release notes through
another major release cycle, I know it's no small undertaking!

Attached is a proposal for the "major enhancements" section. I borrowed
from the press release[1] but tried to stay true to the release notes
format and listed out the enhancements that way.

Open to suggestion, formatting changes, etc.

Thanks!

Jonathan

[1]
https://www.postgresql.org/message-id/3bd579f8-438a-ed1a-ee20-738292099aae%40postgresql.org


Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> Attached is a proposal for the "major enhancements" section. I borrowed
> from the press release[1] but tried to stay true to the release notes
> format and listed out the enhancements that way.

Pushed with some very minor wording tweaks.

            regards, tom lane



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/10/20 1:14 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> Attached is a proposal for the "major enhancements" section. I borrowed
>> from the press release[1] but tried to stay true to the release notes
>> format and listed out the enhancements that way.
>
> Pushed with some very minor wording tweaks.

Thanks! The tweaks were minor enough that it took a few readthroughs to
catch them.

One thing that did not make it through was this:

- <para>2020-XX-XX, CURRENT AS OF 2020-08-09</para>
+ <para>2020-09-24, CURRENT AS OF 2020-09-09</para>

Is the plan to update that at a later date? Understandable if so, but
wanted to check.

Thanks,

Jonathan


Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> One thing that did not make it through was this:

> - <para>2020-XX-XX, CURRENT AS OF 2020-08-09</para>
> + <para>2020-09-24, CURRENT AS OF 2020-09-09</para>

Yeah, that's a placeholder to recall how far back to look for additional
changes to the relnotes, so unless you already read the git history that
far back and concluded nothing needed documenting, that was premature.

(I've just about finished making those updates and making an editorial
pass over the notes, so I will change it in a little bit.)

            regards, tom lane



Re: PG 13 release notes, first draft

From
Tom Lane
Date:
Justin Pryzby <pryzby@telsasoft.com> writes:
> Rebasing onto 3965de54e718600a4703233936e56a3202caf73f, I'm left with:

Sorry, I hadn't seen that you submitted more updates.  I pushed
these with minor additional wordsmithing.

            regards, tom lane



Re: PG 13 release notes, first draft

From
Peter Eisentraut
Date:
On 2020-09-09 22:57, Jonathan S. Katz wrote:
> +    <listitem>
> +     <para>
> +      Parallelized vacuuming of B-tree indexes
> +     </para>
> +    </listitem>

I don't think B-tree indexes are relevant here.  AFAICT, this feature 
applies to all indexes.

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



Re: PG 13 release notes, first draft

From
Masahiko Sawada
Date:
On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-09-09 22:57, Jonathan S. Katz wrote:
> > +    <listitem>
> > +     <para>
> > +      Parallelized vacuuming of B-tree indexes
> > +     </para>
> > +    </listitem>
>
> I don't think B-tree indexes are relevant here.  AFAICT, this feature
> applies to all indexes.
>

Yes, parallel vacuum applies to all types of indexes provided by
PostgreSQL binary, and other types of indexes also can use it.

Regards,

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



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 5:22 AM, Masahiko Sawada wrote:
> On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>>
>> On 2020-09-09 22:57, Jonathan S. Katz wrote:
>>> +    <listitem>
>>> +     <para>
>>> +      Parallelized vacuuming of B-tree indexes
>>> +     </para>
>>> +    </listitem>
>>
>> I don't think B-tree indexes are relevant here.  AFAICT, this feature
>> applies to all indexes.
>>
>
> Yes, parallel vacuum applies to all types of indexes provided by
> PostgreSQL binary, and other types of indexes also can use it.

I'm not sure where I got B-tree from. I've attached a correction.

Thanks,

Jonathan

Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 9/15/20 5:22 AM, Masahiko Sawada wrote:
>> On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> I don't think B-tree indexes are relevant here.  AFAICT, this feature
>>> applies to all indexes.

> I'm not sure where I got B-tree from. I've attached a correction.

Right, pushed.  I clarified the main entry for this a tad, too.

            regards, tom lane



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 9:49 AM, Jonathan S. Katz wrote:
> On 9/15/20 5:22 AM, Masahiko Sawada wrote:
>> On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>>
>>> On 2020-09-09 22:57, Jonathan S. Katz wrote:
>>>> +    <listitem>
>>>> +     <para>
>>>> +      Parallelized vacuuming of B-tree indexes
>>>> +     </para>
>>>> +    </listitem>
>>>
>>> I don't think B-tree indexes are relevant here.  AFAICT, this feature
>>> applies to all indexes.
>>>
>>
>> Yes, parallel vacuum applies to all types of indexes provided by
>> PostgreSQL binary, and other types of indexes also can use it.
>
> I'm not sure where I got B-tree from. I've attached a correction.

On a different note, I became aware of this[1] and noticed that dropping
"CREATE EXTENSION ... FROM" was not listed in the incompatibilities
section, so proposing the attached. I have no strong opinions on the
final wording, mainly wanted to get it listed.

Thanks,

Jonathan

[1] https://trac.osgeo.org/postgis/ticket/4753

Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On a different note, I became aware of this[1] and noticed that dropping
> "CREATE EXTENSION ... FROM" was not listed in the incompatibilities
> section, so proposing the attached. I have no strong opinions on the
> final wording, mainly wanted to get it listed.

It is listed already in the "Additional Modules" section (about line 2940
in release-13.sgml as of right now).  I don't know Bruce's exact reasoning
for not including it in the "Incompatibilities" section, but I tend to
agree that it shouldn't be significant to any real-world user.  I think
that the postgis testing issue you reference is just an ancient test
case that they should drop as no longer relevant.

            regards, tom lane



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 11:45 AM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On a different note, I became aware of this[1] and noticed that dropping
>> "CREATE EXTENSION ... FROM" was not listed in the incompatibilities
>> section, so proposing the attached. I have no strong opinions on the
>> final wording, mainly wanted to get it listed.
>
> It is listed already in the "Additional Modules" section (about line 2940
> in release-13.sgml as of right now).

...sort of. It talks about the feature, but does not talk about the
syntax removal, which is what I was originally searching for in the
release notes.

>  I don't know Bruce's exact reasoning
> for not including it in the "Incompatibilities" section, but I tend to
> agree that it shouldn't be significant to any real-world user.

I do tend agree with this intuitively but don't have any data to back it
up either way. That said, we did modify the command and it would be good
to at least mention the fact we dropped "FROM" somewhere in the release
notes. It provides a good reference in case someone reports an "issue"
in the future stemming from dropping the "FROM" keyword, we can say "oh
it changed in PG13, see XYZ."

(Speaking from having used the release notes to perform similar
troubleshooting).

> I think
> that the postgis testing issue you reference is just an ancient test
> case that they should drop as no longer relevant.

Sure, and AIUI they're going to do that, mostly that was a reference
point to the changed syntax.

Jonathan


Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 9/15/20 11:45 AM, Tom Lane wrote:
>> It is listed already in the "Additional Modules" section (about line 2940
>> in release-13.sgml as of right now).

> ...sort of. It talks about the feature, but does not talk about the
> syntax removal, which is what I was originally searching for in the
> release notes.

Ah.  OK, we can certainly extend it to mention that.  How about
(not bothering with markup yet)

 Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
+
+The FROM option of CREATE EXTENSION is no longer supported.

            regards, tom lane



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 12:05 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 9/15/20 11:45 AM, Tom Lane wrote:
>>> It is listed already in the "Additional Modules" section (about line 2940
>>> in release-13.sgml as of right now).
>
>> ...sort of. It talks about the feature, but does not talk about the
>> syntax removal, which is what I was originally searching for in the
>> release notes.
>
> Ah.  OK, we can certainly extend it to mention that.  How about
> (not bothering with markup yet)
>
>  Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
> +
> +The FROM option of CREATE EXTENSION is no longer supported.

+1.

With that in place, I'm more ambivalent to whether or not it's mentioned
in the incompatibilities section as well, though would lean towards
having a mention of it there as it technically is one. But I don't feel
too strongly about it.

Jonathan


Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 9/15/20 12:05 PM, Tom Lane wrote:
>> Ah.  OK, we can certainly extend it to mention that.  How about
>> (not bothering with markup yet)
>> 
>>  Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
>> +
>> +The FROM option of CREATE EXTENSION is no longer supported.

> +1.

> With that in place, I'm more ambivalent to whether or not it's mentioned
> in the incompatibilities section as well, though would lean towards
> having a mention of it there as it technically is one. But I don't feel
> too strongly about it.

After thinking a bit, I'm inclined to agree that we should move it
to "Incompatibilities".  It is a core server change (third-party
extensions don't have a choice to opt out, as per postgis' issue),
and even if it's trivial, we have some even-more-trivial issues
listed there, like command tag changes.

            regards, tom lane



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 1:05 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 9/15/20 12:05 PM, Tom Lane wrote:
>>> Ah.  OK, we can certainly extend it to mention that.  How about
>>> (not bothering with markup yet)
>>>
>>>  Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
>>> +
>>> +The FROM option of CREATE EXTENSION is no longer supported.
>
>> +1.
>
>> With that in place, I'm more ambivalent to whether or not it's mentioned
>> in the incompatibilities section as well, though would lean towards
>> having a mention of it there as it technically is one. But I don't feel
>> too strongly about it.
>
> After thinking a bit, I'm inclined to agree that we should move it
> to "Incompatibilities".  It is a core server change (third-party
> extensions don't have a choice to opt out, as per postgis' issue),
> and even if it's trivial, we have some even-more-trivial issues
> listed there, like command tag changes.

How about this?

Jonathan

Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 9/15/20 1:05 PM, Tom Lane wrote:
>> After thinking a bit, I'm inclined to agree that we should move it
>> to "Incompatibilities".  It is a core server change (third-party
>> extensions don't have a choice to opt out, as per postgis' issue),
>> and even if it's trivial, we have some even-more-trivial issues
>> listed there, like command tag changes.

> How about this?

The other incompatibilities are only listed once, if they're minor.
I was just about to commit the attached.

            regards, tom lane

diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 1f130ca1fe..3fd97c9d10 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -270,6 +270,25 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
      </para>
     </listitem>

+     <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
+-->
+
+      <para>
+       Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
+      </para>
+
+      <para>
+       The <literal>FROM</literal> option
+       of <link linkend="sql-createextension"><command>CREATE
+       EXTENSION</command></link> is no longer supported.  Any installations
+       still using unpackaged extensions should upgrade them to a packaged
+       version before updating to <productname>PostgreSQL</productname> 13.
+      </para>
+     </listitem>
+
     <listitem>
 <!--
 Author: Tom Lane <tgl@sss.pgh.pa.us>
@@ -2934,17 +2953,6 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>

      <listitem>
 <!--
-Author: Tom Lane <tgl@sss.pgh.pa.us>
-2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
--->
-
-      <para>
-       Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
-      </para>
-     </listitem>
-
-     <listitem>
-<!--
 Author: Andrew Dunstan <andrew@dunslane.net>
 2019-12-20 [6136e94dc] Superuser can permit passwordless connections on postgre
 -->

Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 2:11 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 9/15/20 1:05 PM, Tom Lane wrote:
>>> After thinking a bit, I'm inclined to agree that we should move it
>>> to "Incompatibilities".  It is a core server change (third-party
>>> extensions don't have a choice to opt out, as per postgis' issue),
>>> and even if it's trivial, we have some even-more-trivial issues
>>> listed there, like command tag changes.
>
>> How about this?
>
> The other incompatibilities are only listed once, if they're minor.
> I was just about to commit the attached.

Even better. +1

Jonathan


Attachment

Re: PG 13 release notes, first draft

From
Tom Lane
Date:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 9/15/20 2:11 PM, Tom Lane wrote:
>> The other incompatibilities are only listed once, if they're minor.
>> I was just about to commit the attached.

> Even better. +1

Pushed, thanks for looking.

            regards, tom lane



Re: PG 13 release notes, first draft

From
"Jonathan S. Katz"
Date:
On 9/15/20 2:30 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 9/15/20 2:11 PM, Tom Lane wrote:
>>> The other incompatibilities are only listed once, if they're minor.
>>> I was just about to commit the attached.
>
>> Even better. +1
>
> Pushed, thanks for looking.

Thanks for modifying...though I have a gripe about it being labeled a
gripe[1] ;) Though it gave me a good laugh...

Jonathan

[1]
https://git.postgresql.org/pg/commitdiff/d42c6176446440b185fcb95c214b7e40d5758b60


Attachment

Re: PG 13 release notes, first draft

From
Peter Geoghegan
Date:
On Tue, Sep 15, 2020 at 11:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pushed, thanks for looking.

I think that the Postgres 13 release notes should mention the
enhancement to contrib/amcheck made by Alexander's commit d114cc53.

I suggest something along the lines of: "Make the cross-level
verification checks performed by contrib/amcheck's
bt_index_parent_check() function more robust".

-- 
Peter Geoghegan