Re: PG 13 release notes, first draft

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 +