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 <pe...@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 <br...@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 +
