pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PG 13 release notes, first draft
Date: Tue, 5 May 2020 11:45:03 -0500
Message-ID: <20200505164503.GY28974@telsasoft.com> (raw)
In-Reply-To: <20200505031600.GB21752@momjian.us>
References: <20200505031600.GB21752@momjian.us>

|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





view thread (194+ messages)  latest in thread

Message-ID: <20200505164503.GY28974@telsasoft.com>
Permalink:  ../20200505164503.GY28974@telsasoft.com/
Also on:    postgresql.org/message-id/20200505164503.GY28974@telsasoft.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pryzby@telsasoft.com, bruce@momjian.us
  Subject: Re: PG 13 release notes, first draft
  In-Reply-To: <20200505164503.GY28974@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox