Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit01a11c7

Browse files
committed
Second-draft release notes for 14.1.
Add latest commits. Fix some typos and infelicitous wording(thanks to Justin Pryzby for proof-reading).
1 parentf7829fe commit01a11c7

File tree

1 file changed

+87
-70
lines changed

1 file changed

+87
-70
lines changed

‎doc/src/sgml/release-14.sgml

Lines changed: 87 additions & 70 deletions
Original file line numberDiff line numberDiff line change
@@ -409,7 +409,7 @@ Branch: REL_11_STABLE [0d08c279b] 2021-10-19 13:54:46 -0400
409409

410410
<para>
411411
A command such as <literal>UPDATE tab SET fld[1].subfld =
412-
value</literal> failed if the array elements were domains rather
412+
val</literal> failed if the array's elements were domains rather
413413
than plain composites.
414414
</para>
415415
</listitem>
@@ -427,9 +427,9 @@ Branch: REL_13_STABLE [170206e45] 2021-10-01 18:29:18 -0300
427427
</para>
428428

429429
<para>
430-
<literal>FETCH FIRST WITH TIES</literal> necessarily fetches
431-
onemore row than requested,so thaitcan determine whether the
432-
next rowis a tie or not. In our current implementation,
430+
<literal>FETCH FIRST WITH TIES</literal> necessarily fetches one
431+
more row than requested,sinceitcannot stop until it finds a row
432+
thatisnota tie. In our current implementation,
433433
if <literal>FOR UPDATE</literal> is used then that row will also get
434434
locked even though it is not returned. That results in undesirable
435435
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
454454
</para>
455455

456456
<para>
457-
Previously this was allowed, but the collationeffectively vanished
458-
into the etherbecause of the way collation lookup works: you could
459-
notuse the collation, nor even drop it.
457+
Previously this was allowed, butthenthe collationcould not be
458+
referencedbecause of the way collation lookup works; you could not
459+
use the collation, nor even drop it.
460460
</para>
461461
</listitem>
462462

@@ -473,7 +473,7 @@ Branch: REL_13_STABLE [85dc4292a] 2021-10-19 11:04:04 +0900
473473
</para>
474474

475475
<para>
476-
While the parseraccepts this, it's undocumented and doesn't
476+
While the parseraccepted this, it's undocumented and doesn't
477477
actually work.
478478
</para>
479479
</listitem>
@@ -545,7 +545,7 @@ Branch: REL9_6_STABLE [d90e14414] 2021-08-23 17:41:07 -0400
545545
<para>
546546
The regexp engine was careless about clearing match data
547547
for capturing parentheses after rejecting a partial match. This
548-
could allow a later back-reference tosucceed when by rights it
548+
could allow a later back-reference tomatch in places where it
549549
should fail for lack of a defined referent.
550550
</para>
551551
</listitem>
@@ -567,10 +567,9 @@ Branch: REL9_6_STABLE [cafebd663] 2021-08-20 14:19:04 -0400
567567
</para>
568568

569569
<para>
570-
Unnecessarily stupid back-tracking logic could result in exponential
571-
time spent looking for a match. Fortunately the problem is masked
572-
in most cases by other optimizations; but it is possible to
573-
demonstrate it with fairly simple, if contrived, regexps.
570+
Incorrect back-tracking logic could result in exponential time spent
571+
looking for a match. Fortunately the problem is masked in most
572+
cases by other optimizations.
574573
</para>
575574
</listitem>
576575

@@ -599,49 +598,6 @@ Branch: REL9_6_STABLE [5907c3818] 2021-09-06 11:29:52 -0400
599598
<listitem>
600599
<!--
601600
Author: Tom Lane <tgl@sss.pgh.pa.us>
602-
Branch: master [9b8d68cc6] 2021-10-02 16:05:42 -0400
603-
Branch: REL_14_STABLE [fa8db4879] 2021-10-02 16:06:09 -0400
604-
Branch: REL_13_STABLE [9c76689de] 2021-10-02 16:06:23 -0400
605-
Branch: REL_12_STABLE [e5b25f19b] 2021-10-02 16:06:45 -0400
606-
Branch: REL_11_STABLE [9cc919b51] 2021-10-02 16:06:55 -0400
607-
Branch: REL_10_STABLE [e323630cd] 2021-10-02 16:07:16 -0400
608-
Branch: REL9_6_STABLE [dbec5a2fe] 2021-10-02 16:07:37 -0400
609-
Branch: master [ad740067a] 2021-10-02 16:05:10 -0400
610-
Branch: REL_14_STABLE [81464999b] 2021-10-02 16:06:09 -0400
611-
Branch: REL_13_STABLE [7ba8eb81f] 2021-10-02 16:06:23 -0400
612-
Branch: REL_12_STABLE [4721e8aa6] 2021-10-02 16:06:45 -0400
613-
Branch: REL_11_STABLE [bb6d42669] 2021-10-02 16:06:55 -0400
614-
Branch: REL_10_STABLE [cb0799db0] 2021-10-02 16:07:16 -0400
615-
Branch: REL9_6_STABLE [37cbe0f79] 2021-10-02 16:07:36 -0400
616-
Branch: master [c1aa3b3c0] 2021-10-04 14:52:39 -0400
617-
Branch: REL_14_STABLE [919c08d90] 2021-10-04 14:52:17 -0400
618-
Branch: REL_13_STABLE [c53ff69e1] 2021-10-04 14:52:17 -0400
619-
Branch: REL_12_STABLE [07873a5dc] 2021-10-04 14:52:17 -0400
620-
Branch: REL_11_STABLE [d0b0b70dc] 2021-10-04 14:52:17 -0400
621-
Branch: REL_10_STABLE [cd2479142] 2021-10-04 14:52:17 -0400
622-
Branch: REL9_6_STABLE [b5f34ae08] 2021-10-04 14:52:17 -0400
623-
-->
624-
<para>
625-
Use the CLDR project's data to map Windows time zone names to IANA
626-
time zones (Tom Lane)
627-
</para>
628-
629-
<para>
630-
When running on Windows, <application>initdb</application> attempts
631-
to set the new cluster's <varname>timezone</varname> parameter to
632-
the IANA time zone matching the system's prevailing time zone.
633-
We were using a mapping table that we'd generated years ago and
634-
updated only fitfully; unsurprisingly, it contained a number of
635-
errors as well as omissions of recently-added zones. It turns out
636-
that CLDR has been tracking the most appropriate mappings, so start
637-
using their data. This change will not affect any existing
638-
installation, only newly-initialized clusters.
639-
</para>
640-
</listitem>
641-
642-
<listitem>
643-
<!--
644-
Author: Tom Lane <tgl@sss.pgh.pa.us>
645601
Branch: master [4d5f651f1] 2021-10-14 12:43:55 -0400
646602
Branch: REL_14_STABLE [fd059ac2e] 2021-10-14 12:43:43 -0400
647603
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
765721
Branch: REL9_6_STABLE [e2b2a9e1c] 2021-10-04 14:06:09 +0900
766722
-->
767723
<para>
768-
Ensure prepared transactions are properly accounted for during
724+
Ensurethatprepared transactions are properly accounted for during
769725
promotion of a standby server (Michael Paquier, Andres Freund)
770726
</para>
771727

@@ -959,7 +915,8 @@ Branch: REL_10_STABLE [96f6ef9fe] 2021-08-25 08:55:52 -0400
959915

960916
<para>
961917
This oversight could lead to misbehavior in parallel queries if the
962-
transaction isolation level is less than REPEATABLE READ.
918+
transaction isolation level is less than <literal>REPEATABLE
919+
READ</literal>.
963920
</para>
964921
</listitem>
965922

@@ -1011,14 +968,14 @@ Branch: REL_10_STABLE [f77489046] 2021-09-09 23:59:40 +0900
1011968
Branch: REL9_6_STABLE [61e2aa2db] 2021-09-10 00:00:06 +0900
1012969
-->
1013970
<para>
1014-
Fixwalreceiverto ensure that it creates anarchive notification
1015-
file before exiting (Fujii Masao)
971+
Ensure thatwalreceiverprocesses create all requiredarchive
972+
notification files before exiting (Fujii Masao)
1016973
</para>
1017974

1018975
<para>
1019-
This failed to happen if thewalreceiver exited exactly at a WAL
1020-
segment boundary, thus delaying archiving of thenew segment on the
1021-
standby.
976+
If awalreceiver exited exactly at a WAL segment boundary, it failed
977+
to make a notification file for thelast-received segment, thus
978+
delaying archiving of that segment on thestandby.
1022979
</para>
1023980
</listitem>
1024981

@@ -1033,8 +990,8 @@ Branch: REL_14_STABLE [ae254356f] 2021-10-06 13:28:30 +0900
1033990
Branch: REL_13_STABLE [d6d68e223] 2021-10-06 13:28:35 +0900
1034991
-->
1035992
<para>
1036-
Compute the correctWAL range to include in a backup manifest when a
1037-
timeline change is involved (Kyotaro Horiguchi)
993+
Fix computation of theWAL range to include in a backup manifest
994+
when atimeline change is involved (Kyotaro Horiguchi)
1038995
</para>
1039996
</listitem>
1040997

@@ -1095,8 +1052,8 @@ Branch: REL_13_STABLE [a73a3671d] 2021-10-20 13:05:42 -0300
10951052
Branch: REL_12_STABLE [3c8c49945] 2021-10-20 13:05:42 -0300
10961053
-->
10971054
<para>
1098-
Ensure correct lock level is used when renaming a table (Nathan
1099-
Bossart, &Aacute;lvaro Herrera)
1055+
Ensurethat thecorrect lock level is used when renaming a table
1056+
(NathanBossart, &Aacute;lvaro Herrera)
11001057
</para>
11011058

11021059
<para>
@@ -1267,7 +1224,7 @@ Branch: REL_10_STABLE [4874886b4] 2021-08-13 16:44:18 +1200
12671224
</para>
12681225

12691226
<para>
1270-
It seems unlikely that this bug hasyetbeen hit in practice, as it
1227+
It seems unlikely that this bug has been hit in practice, as it
12711228
would require <varname>work_mem</varname> settings of hundreds of
12721229
gigabytes for existing uses of <filename>simplehash.h</filename>.
12731230
</para>
@@ -1348,6 +1305,23 @@ Branch: REL_13_STABLE [d5a2ffbce] 2021-10-27 13:09:00 -0700
13481305

13491306
<listitem>
13501307
<!--
1308+
Author: Tomas Vondra <tomas.vondra@postgresql.org>
1309+
Branch: master [d91353f4b] 2021-11-06 01:50:44 +0100
1310+
Branch: REL_14_STABLE [f7829feb7] 2021-11-06 01:53:36 +0100
1311+
-->
1312+
<para>
1313+
Avoid assertion failure when inserting NaN into a BRIN
1314+
float8 or float4 minmax_multi_ops index (Tomas Vondra)
1315+
</para>
1316+
1317+
<para>
1318+
In production builds, such cases would result in a somewhat
1319+
inefficient, but not actually incorrect, index.
1320+
</para>
1321+
</listitem>
1322+
1323+
<listitem>
1324+
<!--
13511325
Author: Fujii Masao <fujii@postgresql.org>
13521326
Branch: master [e3e29cec1] 2021-10-12 09:50:17 +0900
13531327
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
15411515
PRIVILEGES</command> command revoked some present-by-default
15421516
privilege, for example <literal>EXECUTE</literal> for functions, and
15431517
then a restricted <command>ALTER DEFAULT PRIVILEGES</command>
1544-
command granted that privilegeback for a selected role or
1518+
command granted that privilegeagain for a selected role or
15451519
schema, <application>pg_dump</application> failed to dump the
15461520
restricted privilege grant correctly.
15471521
</para>
@@ -1598,7 +1572,7 @@ Branch: REL9_6_STABLE [4645997c8] 2021-08-31 13:53:33 -0400
15981572
<para>
15991573
These changes provide only marginal improvement when dumping from a
16001574
local server, but a dump from a remote server can benefit
1601-
substantially.
1575+
substantially due to fewer network round-trips.
16021576
</para>
16031577
</listitem>
16041578

@@ -1920,6 +1894,49 @@ Branch: REL_14_STABLE [52c0c1136] 2021-10-22 09:50:16 -0400
19201894
<listitem>
19211895
<!--
19221896
Author: Tom Lane <tgl@sss.pgh.pa.us>
1897+
Branch: master [9b8d68cc6] 2021-10-02 16:05:42 -0400
1898+
Branch: REL_14_STABLE [fa8db4879] 2021-10-02 16:06:09 -0400
1899+
Branch: REL_13_STABLE [9c76689de] 2021-10-02 16:06:23 -0400
1900+
Branch: REL_12_STABLE [e5b25f19b] 2021-10-02 16:06:45 -0400
1901+
Branch: REL_11_STABLE [9cc919b51] 2021-10-02 16:06:55 -0400
1902+
Branch: REL_10_STABLE [e323630cd] 2021-10-02 16:07:16 -0400
1903+
Branch: REL9_6_STABLE [dbec5a2fe] 2021-10-02 16:07:37 -0400
1904+
Branch: master [ad740067a] 2021-10-02 16:05:10 -0400
1905+
Branch: REL_14_STABLE [81464999b] 2021-10-02 16:06:09 -0400
1906+
Branch: REL_13_STABLE [7ba8eb81f] 2021-10-02 16:06:23 -0400
1907+
Branch: REL_12_STABLE [4721e8aa6] 2021-10-02 16:06:45 -0400
1908+
Branch: REL_11_STABLE [bb6d42669] 2021-10-02 16:06:55 -0400
1909+
Branch: REL_10_STABLE [cb0799db0] 2021-10-02 16:07:16 -0400
1910+
Branch: REL9_6_STABLE [37cbe0f79] 2021-10-02 16:07:36 -0400
1911+
Branch: master [c1aa3b3c0] 2021-10-04 14:52:39 -0400
1912+
Branch: REL_14_STABLE [919c08d90] 2021-10-04 14:52:17 -0400
1913+
Branch: REL_13_STABLE [c53ff69e1] 2021-10-04 14:52:17 -0400
1914+
Branch: REL_12_STABLE [07873a5dc] 2021-10-04 14:52:17 -0400
1915+
Branch: REL_11_STABLE [d0b0b70dc] 2021-10-04 14:52:17 -0400
1916+
Branch: REL_10_STABLE [cd2479142] 2021-10-04 14:52:17 -0400
1917+
Branch: REL9_6_STABLE [b5f34ae08] 2021-10-04 14:52:17 -0400
1918+
-->
1919+
<para>
1920+
Use the CLDR project's data to map Windows time zone names to IANA
1921+
time zones (Tom Lane)
1922+
</para>
1923+
1924+
<para>
1925+
When running on Windows, <application>initdb</application> attempts
1926+
to set the new cluster's <varname>timezone</varname> parameter to
1927+
the IANA time zone matching the system's prevailing time zone.
1928+
We were using a mapping table that we'd generated years ago and
1929+
updated only fitfully; unsurprisingly, it contained a number of
1930+
errors as well as omissions of recently-added zones. It turns out
1931+
that CLDR has been tracking the most appropriate mappings, so start
1932+
using their data. This change will not affect any existing
1933+
installation, only newly-initialized clusters.
1934+
</para>
1935+
</listitem>
1936+
1937+
<listitem>
1938+
<!--
1939+
Author: Tom Lane <tgl@sss.pgh.pa.us>
19231940
Branch: master [937aafd6d] 2021-10-29 11:38:18 -0400
19241941
Branch: REL_14_STABLE [0c8a40b39] 2021-10-29 11:38:32 -0400
19251942
Branch: REL_13_STABLE [4cd72add0] 2021-10-29 11:38:38 -0400

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp