Second-draft release notes for 14.1.
Add latest commits. Fix some typos and infelicitous wording (thanks to Justin Pryzby for proof-reading).
This commit is contained in:
Tom Lane
parent
f7829feb75
commit
01a11c77be
@ -409,7 +409,7 @@ Branch: REL_11_STABLE [0d08c279b] 2021-10-19 13:54:46 -0400
|
||||
|
||||
<para>
|
||||
A command such as <literal>UPDATE tab SET fld[1].subfld =
|
||||
value</literal> failed if the array elements were domains rather
|
||||
val</literal> failed if the array's elements were domains rather
|
||||
than plain composites.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -427,9 +427,9 @@ Branch: REL_13_STABLE [170206e45] 2021-10-01 18:29:18 -0300
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<literal>FETCH FIRST WITH TIES</literal> necessarily fetches
|
||||
one more row than requested, so tha it can determine whether the
|
||||
next row is a tie or not. In our current implementation,
|
||||
<literal>FETCH FIRST WITH TIES</literal> necessarily fetches one
|
||||
more row than requested, since it cannot stop until it finds a row
|
||||
that is not a tie. In our current implementation,
|
||||
if <literal>FOR UPDATE</literal> is used then that row will also get
|
||||
locked even though it is not returned. That results in undesirable
|
||||
behavior if the <literal>SKIP LOCKED</literal> option is specified.
|
||||
@ -454,9 +454,9 @@ Branch: REL_10_STABLE [5d7c6b6c8] 2021-09-03 16:38:55 -0400
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Previously this was allowed, but the collation effectively vanished
|
||||
into the ether because of the way collation lookup works: you could
|
||||
not use the collation, nor even drop it.
|
||||
Previously this was allowed, but then the collation could not be
|
||||
referenced because of the way collation lookup works; you could not
|
||||
use the collation, nor even drop it.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -473,7 +473,7 @@ Branch: REL_13_STABLE [85dc4292a] 2021-10-19 11:04:04 +0900
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While the parser accepts this, it's undocumented and doesn't
|
||||
While the parser accepted this, it's undocumented and doesn't
|
||||
actually work.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -545,7 +545,7 @@ Branch: REL9_6_STABLE [d90e14414] 2021-08-23 17:41:07 -0400
|
||||
<para>
|
||||
The regexp engine was careless about clearing match data
|
||||
for capturing parentheses after rejecting a partial match. This
|
||||
could allow a later back-reference to succeed when by rights it
|
||||
could allow a later back-reference to match in places where it
|
||||
should fail for lack of a defined referent.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -567,10 +567,9 @@ Branch: REL9_6_STABLE [cafebd663] 2021-08-20 14:19:04 -0400
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Unnecessarily stupid back-tracking logic could result in exponential
|
||||
time spent looking for a match. Fortunately the problem is masked
|
||||
in most cases by other optimizations; but it is possible to
|
||||
demonstrate it with fairly simple, if contrived, regexps.
|
||||
Incorrect back-tracking logic could result in exponential time spent
|
||||
looking for a match. Fortunately the problem is masked in most
|
||||
cases by other optimizations.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -599,49 +598,6 @@ Branch: REL9_6_STABLE [5907c3818] 2021-09-06 11:29:52 -0400
|
||||
<listitem>
|
||||
<!--
|
||||
Author: Tom Lane <tgl@sss.pgh.pa.us>
|
||||
Branch: master [9b8d68cc6] 2021-10-02 16:05:42 -0400
|
||||
Branch: REL_14_STABLE [fa8db4879] 2021-10-02 16:06:09 -0400
|
||||
Branch: REL_13_STABLE [9c76689de] 2021-10-02 16:06:23 -0400
|
||||
Branch: REL_12_STABLE [e5b25f19b] 2021-10-02 16:06:45 -0400
|
||||
Branch: REL_11_STABLE [9cc919b51] 2021-10-02 16:06:55 -0400
|
||||
Branch: REL_10_STABLE [e323630cd] 2021-10-02 16:07:16 -0400
|
||||
Branch: REL9_6_STABLE [dbec5a2fe] 2021-10-02 16:07:37 -0400
|
||||
Branch: master [ad740067a] 2021-10-02 16:05:10 -0400
|
||||
Branch: REL_14_STABLE [81464999b] 2021-10-02 16:06:09 -0400
|
||||
Branch: REL_13_STABLE [7ba8eb81f] 2021-10-02 16:06:23 -0400
|
||||
Branch: REL_12_STABLE [4721e8aa6] 2021-10-02 16:06:45 -0400
|
||||
Branch: REL_11_STABLE [bb6d42669] 2021-10-02 16:06:55 -0400
|
||||
Branch: REL_10_STABLE [cb0799db0] 2021-10-02 16:07:16 -0400
|
||||
Branch: REL9_6_STABLE [37cbe0f79] 2021-10-02 16:07:36 -0400
|
||||
Branch: master [c1aa3b3c0] 2021-10-04 14:52:39 -0400
|
||||
Branch: REL_14_STABLE [919c08d90] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_13_STABLE [c53ff69e1] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_12_STABLE [07873a5dc] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_11_STABLE [d0b0b70dc] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_10_STABLE [cd2479142] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL9_6_STABLE [b5f34ae08] 2021-10-04 14:52:17 -0400
|
||||
-->
|
||||
<para>
|
||||
Use the CLDR project's data to map Windows time zone names to IANA
|
||||
time zones (Tom Lane)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When running on Windows, <application>initdb</application> attempts
|
||||
to set the new cluster's <varname>timezone</varname> parameter to
|
||||
the IANA time zone matching the system's prevailing time zone.
|
||||
We were using a mapping table that we'd generated years ago and
|
||||
updated only fitfully; unsurprisingly, it contained a number of
|
||||
errors as well as omissions of recently-added zones. It turns out
|
||||
that CLDR has been tracking the most appropriate mappings, so start
|
||||
using their data. This change will not affect any existing
|
||||
installation, only newly-initialized clusters.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<!--
|
||||
Author: Tom Lane <tgl@sss.pgh.pa.us>
|
||||
Branch: master [4d5f651f1] 2021-10-14 12:43:55 -0400
|
||||
Branch: REL_14_STABLE [fd059ac2e] 2021-10-14 12:43:43 -0400
|
||||
Branch: REL_13_STABLE [fdd6a4d8d] 2021-10-14 12:43:43 -0400
|
||||
@ -765,7 +721,7 @@ Branch: REL_10_STABLE [8a6a1fe07] 2021-10-04 14:06:03 +0900
|
||||
Branch: REL9_6_STABLE [e2b2a9e1c] 2021-10-04 14:06:09 +0900
|
||||
-->
|
||||
<para>
|
||||
Ensure prepared transactions are properly accounted for during
|
||||
Ensure that prepared transactions are properly accounted for during
|
||||
promotion of a standby server (Michael Paquier, Andres Freund)
|
||||
</para>
|
||||
|
||||
@ -959,7 +915,8 @@ Branch: REL_10_STABLE [96f6ef9fe] 2021-08-25 08:55:52 -0400
|
||||
|
||||
<para>
|
||||
This oversight could lead to misbehavior in parallel queries if the
|
||||
transaction isolation level is less than REPEATABLE READ.
|
||||
transaction isolation level is less than <literal>REPEATABLE
|
||||
READ</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1011,14 +968,14 @@ Branch: REL_10_STABLE [f77489046] 2021-09-09 23:59:40 +0900
|
||||
Branch: REL9_6_STABLE [61e2aa2db] 2021-09-10 00:00:06 +0900
|
||||
-->
|
||||
<para>
|
||||
Fix walreceiver to ensure that it creates an archive notification
|
||||
file before exiting (Fujii Masao)
|
||||
Ensure that walreceiver processes create all required archive
|
||||
notification files before exiting (Fujii Masao)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This failed to happen if the walreceiver exited exactly at a WAL
|
||||
segment boundary, thus delaying archiving of the new segment on the
|
||||
standby.
|
||||
If a walreceiver exited exactly at a WAL segment boundary, it failed
|
||||
to make a notification file for the last-received segment, thus
|
||||
delaying archiving of that segment on the standby.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1033,8 +990,8 @@ Branch: REL_14_STABLE [ae254356f] 2021-10-06 13:28:30 +0900
|
||||
Branch: REL_13_STABLE [d6d68e223] 2021-10-06 13:28:35 +0900
|
||||
-->
|
||||
<para>
|
||||
Compute the correct WAL range to include in a backup manifest when a
|
||||
timeline change is involved (Kyotaro Horiguchi)
|
||||
Fix computation of the WAL range to include in a backup manifest
|
||||
when a timeline change is involved (Kyotaro Horiguchi)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1095,8 +1052,8 @@ Branch: REL_13_STABLE [a73a3671d] 2021-10-20 13:05:42 -0300
|
||||
Branch: REL_12_STABLE [3c8c49945] 2021-10-20 13:05:42 -0300
|
||||
-->
|
||||
<para>
|
||||
Ensure correct lock level is used when renaming a table (Nathan
|
||||
Bossart, Álvaro Herrera)
|
||||
Ensure that the correct lock level is used when renaming a table
|
||||
(Nathan Bossart, Álvaro Herrera)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1267,7 +1224,7 @@ Branch: REL_10_STABLE [4874886b4] 2021-08-13 16:44:18 +1200
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It seems unlikely that this bug has yet been hit in practice, as it
|
||||
It seems unlikely that this bug has been hit in practice, as it
|
||||
would require <varname>work_mem</varname> settings of hundreds of
|
||||
gigabytes for existing uses of <filename>simplehash.h</filename>.
|
||||
</para>
|
||||
@ -1348,6 +1305,23 @@ Branch: REL_13_STABLE [d5a2ffbce] 2021-10-27 13:09:00 -0700
|
||||
|
||||
<listitem>
|
||||
<!--
|
||||
Author: Tomas Vondra <tomas.vondra@postgresql.org>
|
||||
Branch: master [d91353f4b] 2021-11-06 01:50:44 +0100
|
||||
Branch: REL_14_STABLE [f7829feb7] 2021-11-06 01:53:36 +0100
|
||||
-->
|
||||
<para>
|
||||
Avoid assertion failure when inserting NaN into a BRIN
|
||||
float8 or float4 minmax_multi_ops index (Tomas Vondra)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In production builds, such cases would result in a somewhat
|
||||
inefficient, but not actually incorrect, index.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<!--
|
||||
Author: Fujii Masao <fujii@postgresql.org>
|
||||
Branch: master [e3e29cec1] 2021-10-12 09:50:17 +0900
|
||||
Branch: REL_14_STABLE [62e821ad2] 2021-10-12 09:51:17 +0900
|
||||
@ -1541,7 +1515,7 @@ Branch: REL9_6_STABLE [b1df061f7] 2021-10-22 15:22:26 -0400
|
||||
PRIVILEGES</command> command revoked some present-by-default
|
||||
privilege, for example <literal>EXECUTE</literal> for functions, and
|
||||
then a restricted <command>ALTER DEFAULT PRIVILEGES</command>
|
||||
command granted that privilege back for a selected role or
|
||||
command granted that privilege again for a selected role or
|
||||
schema, <application>pg_dump</application> failed to dump the
|
||||
restricted privilege grant correctly.
|
||||
</para>
|
||||
@ -1598,7 +1572,7 @@ Branch: REL9_6_STABLE [4645997c8] 2021-08-31 13:53:33 -0400
|
||||
<para>
|
||||
These changes provide only marginal improvement when dumping from a
|
||||
local server, but a dump from a remote server can benefit
|
||||
substantially.
|
||||
substantially due to fewer network round-trips.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1920,6 +1894,49 @@ Branch: REL_14_STABLE [52c0c1136] 2021-10-22 09:50:16 -0400
|
||||
<listitem>
|
||||
<!--
|
||||
Author: Tom Lane <tgl@sss.pgh.pa.us>
|
||||
Branch: master [9b8d68cc6] 2021-10-02 16:05:42 -0400
|
||||
Branch: REL_14_STABLE [fa8db4879] 2021-10-02 16:06:09 -0400
|
||||
Branch: REL_13_STABLE [9c76689de] 2021-10-02 16:06:23 -0400
|
||||
Branch: REL_12_STABLE [e5b25f19b] 2021-10-02 16:06:45 -0400
|
||||
Branch: REL_11_STABLE [9cc919b51] 2021-10-02 16:06:55 -0400
|
||||
Branch: REL_10_STABLE [e323630cd] 2021-10-02 16:07:16 -0400
|
||||
Branch: REL9_6_STABLE [dbec5a2fe] 2021-10-02 16:07:37 -0400
|
||||
Branch: master [ad740067a] 2021-10-02 16:05:10 -0400
|
||||
Branch: REL_14_STABLE [81464999b] 2021-10-02 16:06:09 -0400
|
||||
Branch: REL_13_STABLE [7ba8eb81f] 2021-10-02 16:06:23 -0400
|
||||
Branch: REL_12_STABLE [4721e8aa6] 2021-10-02 16:06:45 -0400
|
||||
Branch: REL_11_STABLE [bb6d42669] 2021-10-02 16:06:55 -0400
|
||||
Branch: REL_10_STABLE [cb0799db0] 2021-10-02 16:07:16 -0400
|
||||
Branch: REL9_6_STABLE [37cbe0f79] 2021-10-02 16:07:36 -0400
|
||||
Branch: master [c1aa3b3c0] 2021-10-04 14:52:39 -0400
|
||||
Branch: REL_14_STABLE [919c08d90] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_13_STABLE [c53ff69e1] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_12_STABLE [07873a5dc] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_11_STABLE [d0b0b70dc] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL_10_STABLE [cd2479142] 2021-10-04 14:52:17 -0400
|
||||
Branch: REL9_6_STABLE [b5f34ae08] 2021-10-04 14:52:17 -0400
|
||||
-->
|
||||
<para>
|
||||
Use the CLDR project's data to map Windows time zone names to IANA
|
||||
time zones (Tom Lane)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When running on Windows, <application>initdb</application> attempts
|
||||
to set the new cluster's <varname>timezone</varname> parameter to
|
||||
the IANA time zone matching the system's prevailing time zone.
|
||||
We were using a mapping table that we'd generated years ago and
|
||||
updated only fitfully; unsurprisingly, it contained a number of
|
||||
errors as well as omissions of recently-added zones. It turns out
|
||||
that CLDR has been tracking the most appropriate mappings, so start
|
||||
using their data. This change will not affect any existing
|
||||
installation, only newly-initialized clusters.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<!--
|
||||
Author: Tom Lane <tgl@sss.pgh.pa.us>
|
||||
Branch: master [937aafd6d] 2021-10-29 11:38:18 -0400
|
||||
Branch: REL_14_STABLE [0c8a40b39] 2021-10-29 11:38:32 -0400
|
||||
Branch: REL_13_STABLE [4cd72add0] 2021-10-29 11:38:38 -0400
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user