6
6
7
7
<formalpara>
8
8
<title>Release date:</title>
9
- <para>2020-XX-XX, CURRENT AS OF 2020-05-03 </para>
9
+ <para>2020-XX-XX, CURRENT AS OF 2020-08-09 </para>
10
10
</formalpara>
11
11
12
12
<sect2>
21
21
<itemizedlist>
22
22
23
23
<listitem>
24
- <para></para>
24
+ <para>TBD </para>
25
25
</listitem>
26
26
27
27
</itemizedlist>
@@ -141,33 +141,18 @@ Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
141
141
142
142
<listitem>
143
143
<!--
144
- Author: Peter Geoghegan <pg@bowt.ie>
145
- 2020-03-07 [691e8b2e1] pageinspect: Fix types used for bt_metap() columns.
146
- -->
147
-
148
- <para>
149
- Fix <xref linkend="pageinspect"/>'s <function>bt_metap()</function>
150
- to return more appropriate data types that are less likely to overflow
151
- (Peter Geoghegan)
152
- </para>
153
- </listitem>
154
-
155
- <listitem>
156
- <!--
157
144
Author: Fujii Masao <fujii@postgresql.org>
158
145
2020-03-19 [1d253bae5] Rename the recovery-related wait events.
146
+ Author: Tom Lane <tgl@sss.pgh.pa.us>
147
+ 2020-05-15 [36ac359d3] Rename assorted LWLock tranches.
148
+ 2020-05-15 [474e7da64] Change locktype "speculative token" to "spectoken".
149
+ 2020-05-15 [14a910109] Drop the redundant "Lock" suffix from LWLock wait event
150
+ 2020-05-16 [3048898e7] Mop-up for wait event naming issues.
159
151
-->
160
152
161
153
<para>
162
- Rename some recovery-related <link linkend="wait-event-table">wait
163
- events</link> (Fujii Masao)
164
- </para>
165
-
166
- <para>
167
- Rename <literal>RecoveryWalAll</literal>
168
- to <literal>RecoveryWalStream</literal>
169
- and <literal>RecoveryWalStream</literal> to
170
- <literal>RecoveryRetrieveRetryInterval</literal>.
154
+ Rename various <link linkend="wait-event-table">wait
155
+ events</link> to improve consistency (Fujii Masao, Tom Lane)
171
156
</para>
172
157
</listitem>
173
158
@@ -269,6 +254,46 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
269
254
</para>
270
255
</listitem>
271
256
257
+ <listitem>
258
+ <!--
259
+ Author: Tom Lane <tgl@sss.pgh.pa.us>
260
+ 2020-06-29 [21aac2ff9] Remove support for timezone "posixrules" file.
261
+ -->
262
+
263
+ <para>
264
+ Remove support for <filename>posixrules</filename> files in the
265
+ timezone database (Tom Lane)
266
+ </para>
267
+
268
+ <para>
269
+ IANA's timezone group has deprecated this feature, meaning that it
270
+ will gradually disappear from systems' timezone databases over the
271
+ next few years. Rather than have a behavioral change appear
272
+ unexpectedly with a timezone data update, we have
273
+ removed <productname>PostgreSQL</productname>'s support for this
274
+ feature as of version 13. This affects only the behavior
275
+ of <link linkend="datetime-posix-timezone-specs">POSIX-style time
276
+ zone specifications</link> that lack an explicit daylight savings
277
+ transition rule; formerly the transition rule could be determined
278
+ by installing a custom <filename>posixrules</filename> file, but
279
+ now it is hard-wired. The recommended fix for any affected
280
+ installations is to start using a geographical time zone name.
281
+ </para>
282
+ </listitem>
283
+
284
+ <listitem>
285
+ <!--
286
+ Author: Peter Geoghegan <pg@bowt.ie>
287
+ 2020-03-07 [691e8b2e1] pageinspect: Fix types used for bt_metap() columns.
288
+ -->
289
+
290
+ <para>
291
+ Fix <xref linkend="pageinspect"/>'s <function>bt_metap()</function>
292
+ to return more appropriate data types that are less likely to overflow
293
+ (Peter Geoghegan)
294
+ </para>
295
+ </listitem>
296
+
272
297
</itemizedlist>
273
298
274
299
</sect2>
@@ -607,6 +632,8 @@ Author: Tom Lane <tgl@sss.pgh.pa.us>
607
632
<!--
608
633
Author: Tomas Vondra <tomas.vondra@postgresql.org>
609
634
2020-04-06 [d2d8a229b] Implement Incremental Sort
635
+ Author: Peter Eisentraut <peter@eisentraut.org>
636
+ 2020-07-05 [94e454cdd] Rename enable_incrementalsort for clarity
610
637
-->
611
638
612
639
<para>
@@ -640,32 +667,29 @@ Author: Jeff Davis <jdavis@postgresql.org>
640
667
2020-03-18 [1f39bce02] Disk-based Hash Aggregation.
641
668
Author: Jeff Davis <jdavis@postgresql.org>
642
669
2020-03-24 [dd8e19132] Consider disk-based hash aggregation to implement DISTIN
670
+ Author: Peter Geoghegan <pg@bowt.ie>
671
+ 2020-07-29 [78530c8e7] Add hash_mem_multiplier GUC.
643
672
-->
644
673
645
674
<para>
646
675
Allow <link linkend="guc-enable-hashagg">hash aggregation</link>
676
+ and <link linkend="queries-grouping-sets">grouping sets</link>
647
677
to use disk storage for large aggregation result sets (Jeff Davis)
648
678
</para>
649
679
650
680
<para>
651
681
Previously, hash aggregation was avoided if it was expected to use
652
- more than <xref linkend="guc-work-mem"/> memory. To reduce the
653
- likelihood of using disk storage for hash aggregation and attain
654
- behavior similar to previous Postgres releases, increase <xref
655
- linkend="guc-hash-mem-multiplier"/>.
682
+ more than <xref linkend="guc-work-mem"/> memory. Now, a hash
683
+ aggregation plan can be chosen despite that. The hash table will
684
+ be spilled to disk if it exceeds <varname>work_mem</varname> times
685
+ <xref linkend="guc-hash-mem-multiplier"/>.
656
686
</para>
657
- </listitem>
658
-
659
- <listitem>
660
- <!--
661
- Author: Jeff Davis <jdavis@postgresql.org>
662
- 2020-03-18 [1f39bce02] Disk-based Hash Aggregation.
663
- -->
664
687
665
688
<para>
666
- Allow <link linkend="queries-grouping-sets">grouping sets</link> to
667
- use hash aggregation with disk storage for large grouping set results
668
- (Jeff Davis)
689
+ This behavior is normally preferable to the old behavior. But if
690
+ it is inferior for a particular query, behavior similar to
691
+ previous Postgres releases can be obtained by
692
+ increasing <varname>hash_mem_multiplier</varname>.
669
693
</para>
670
694
</listitem>
671
695
@@ -925,6 +949,8 @@ Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
925
949
<!--
926
950
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
927
951
2019-11-08 [71a8a4f6e] Add backtrace support for error reporting
952
+ Author: Peter Eisentraut <peter@eisentraut.org>
953
+ 2020-07-10 [8ff4d1277] Log the location field before any backtrace
928
954
-->
929
955
930
956
<para>
@@ -1154,8 +1180,8 @@ Author: Peter Eisentraut <peter@eisentraut.org>
1154
1180
-->
1155
1181
1156
1182
<para>
1157
- Change the default minimum <acronym>TLS</acronym> version from 1.0
1158
- to 1.2 (Peter Eisentraut)
1183
+ Change the server's default minimum <acronym>TLS</acronym> version
1184
+ for encrypted connections from 1.0 to 1.2 (Peter Eisentraut)
1159
1185
</para>
1160
1186
1161
1187
<para>
@@ -1984,7 +2010,8 @@ Author: Jeff Davis <jdavis@postgresql.org>
1984
2010
-->
1985
2011
1986
2012
<para>
1987
- Allow libpq clients to require channel binding (Jeff Davis)
2013
+ Allow libpq clients to require channel binding for encrypted
2014
+ connections (Jeff Davis)
1988
2015
</para>
1989
2016
1990
2017
<para>
@@ -2001,17 +2028,22 @@ Author: Michael Paquier <michael@paquier.xyz>
2001
2028
2020-01-28 [ff8ca5fad] Add connection parameters to control SSL protocol min/ma
2002
2029
Author: Michael Paquier <michael@paquier.xyz>
2003
2030
2020-04-30 [401aad670] Rename connection parameters to control min/max SSL prot
2031
+ Author: Tom Lane <tgl@sss.pgh.pa.us>
2032
+ 2020-06-27 [16412c784] Change libpq's default ssl_min_protocol_version to TLSv1
2004
2033
-->
2005
2034
2006
2035
<para>
2007
2036
Add libpq connection parameters to control the min/max
2008
- <acronym>TLS</acronym> version (Daniel Gustafsson)
2037
+ <acronym>TLS</acronym> version for encrypted connections
2038
+ (Daniel Gustafsson)
2009
2039
</para>
2010
2040
2011
2041
<para>
2012
2042
The settings are <xref
2013
2043
linkend="libpq-connect-ssl-min-protocol-version"/> and <xref
2014
2044
linkend="libpq-connect-ssl-max-protocol-version"/>.
2045
+ By default, the minimum <acronym>TLS</acronym> version is 1.2
2046
+ (this represents a behavioral change from previous releases).
2015
2047
</para>
2016
2048
</listitem>
2017
2049
@@ -2022,7 +2054,7 @@ Author: Fujii Masao <fujii@postgresql.org>
2022
2054
-->
2023
2055
2024
2056
<para>
2025
- Tighten line length and comment detection in <link
2057
+ Tighten libpq's overlength- line handling and comment detection for <link
2026
2058
linkend="libpq-pgpass">.pgpass</link> files (Fujii Masao)
2027
2059
</para>
2028
2060
</listitem>
@@ -2056,6 +2088,26 @@ Author: Andrew Dunstan <andrew@dunslane.net>
2056
2088
</para>
2057
2089
</listitem>
2058
2090
2091
+ <listitem>
2092
+ <!--
2093
+ Author: Tom Lane <tgl@sss.pgh.pa.us>
2094
+ 2020-08-03 [44cd434ec] Fix behavior of ecpg's "EXEC SQL elif name".
2095
+ -->
2096
+
2097
+ <para>
2098
+ Fix <application>ecpg</application>'s <literal>EXEC SQL
2099
+ elif</literal> directive to work correctly (Tom Lane)
2100
+ </para>
2101
+
2102
+ <para>
2103
+ Previously it behaved the same as <literal>endif</literal> followed
2104
+ by <literal>ifdef</literal>, so that a successful previous branch
2105
+ of the same <literal>if</literal> construct did not prevent
2106
+ expansion of the <literal>elif</literal> branch or following
2107
+ branches.
2108
+ </para>
2109
+ </listitem>
2110
+
2059
2111
</itemizedlist>
2060
2112
2061
2113
</sect3>
@@ -2798,6 +2850,25 @@ Author: Michael Paquier <michael@paquier.xyz>
2798
2850
</para>
2799
2851
</listitem>
2800
2852
2853
+ <listitem>
2854
+ <!--
2855
+ Author: Tom Lane <tgl@sss.pgh.pa.us>
2856
+ 2020-07-24 [92fe6895d] Fix assorted bugs by changing TS_execute's callback API
2857
+ 2020-07-24 [70eca6a9a] Replace TS_execute's TS_EXEC_CALC_NOT flag with TS_EXEC_
2858
+ -->
2859
+
2860
+ <para>
2861
+ Change the API for <function>TS_execute()</function> (Tom Lane,
2862
+ Pavel Borisov)
2863
+ </para>
2864
+
2865
+ <para>
2866
+ <function>TS_execute</function> callbacks must now provide ternary
2867
+ (yes/no/maybe) logic. Calculating NOT queries accurately is now
2868
+ the default.
2869
+ </para>
2870
+ </listitem>
2871
+
2801
2872
</itemizedlist>
2802
2873
2803
2874
</sect3>
@@ -2915,6 +2986,7 @@ Author: Andrew Gierth <rhodiumtoad@postgresql.org>
2915
2986
<!--
2916
2987
Author: Fujii Masao <fujii@postgresql.org>
2917
2988
2020-04-02 [17e032822] Allow pg_stat_statements to track planning statistics.
2989
+ 2020-07-03 [8d459762b] Change default of pg_stat_statements.track_planning to o
2918
2990
-->
2919
2991
2920
2992
<para>
0 commit comments