Date: Tue, 5 May 2020 16:29:37 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PG 13 release notes, first draft
Message-ID: <20200505202937.GL21185@momjian.us>
References: <20200505183716.GH21185@momjian.us>
 <20200505194437.GA20275@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200505194437.GA20275@alvherre.pgsql>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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, &Aacute;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 +