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(at)eisentraut(dot)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, &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.

> > 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(at)momjian(dot)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 +