rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Release notes for 12.4, 11.9, 10.14, 9.6.19, 9.5.23.

This commit is contained in:
Tom Lane 2020-08-08 20:01:41 -04:00
parent 1fa6eec974
commit ae2d34478c
1 changed files with 976 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

976
doc/src/sgml/release-11.sgml
View File

@ -1,6 +1,982 @@
<!-- doc/src/sgml/release-11.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-11-9">
<title>Release 11.9</title>
<formalpara>
<title>Release date:</title>
<para>2020-08-13</para>
</formalpara>
<para>
This release contains a variety of fixes from 11.8.
For information about new features in major release 11, see
<xref linkend="release-11"/>.
</para>
<sect2>
<title>Migration to Version 11.9</title>
<para>
A dump/restore is not required for those running 11.X.
</para>
<para>
However, if you are upgrading from a version earlier than 11.6,
see <xref linkend="release-11-6"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [13838740f] 2020-07-28 11:00:00 +0900
Branch: REL_13_STABLE [cebe10a5f] 2020-07-28 11:00:00 +0900
Branch: REL_12_STABLE [62c4a7729] 2020-07-28 11:00:02 +0900
Branch: REL_11_STABLE [bead29dec] 2020-07-28 11:00:03 +0900
Branch: master [199cec977] 2020-08-07 14:45:00 +0900
Branch: REL_13_STABLE [79a3ab1e9] 2020-08-07 14:45:01 +0900
Branch: REL_12_STABLE [4f2693229] 2020-08-07 14:45:02 +0900
Branch: REL_11_STABLE [1db9c80f8] 2020-08-07 14:45:04 +0900
-->
<para>
Fix edge cases in partition pruning (Etsuro Fujita, Dmitry Dolgov)
</para>
<para>
When there are multiple partition key columns, generation of pruning
tests could misbehave if some columns had no
constraining <literal>WHERE</literal> clauses or multiple
constraining clauses. This could lead to server crashes, incorrect
query results, or assertion failures.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [689696c71] 2020-07-14 18:56:56 -0400
Branch: REL_13_STABLE [e38705b5c] 2020-07-14 18:56:49 -0400
Branch: REL_12_STABLE [de797e823] 2020-07-14 18:56:49 -0400
Branch: REL_11_STABLE [e9f031172] 2020-07-14 18:56:49 -0400
-->
<para>
Fix construction of parameterized BitmapAnd and BitmapOr index scans
on the inside of partition-wise nestloop joins (Tom Lane)
</para>
<para>
A plan in which such a scan needed to use a value from the outside
of the join would usually crash at execution.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [470687b4a] 2020-08-08 12:31:55 -0400
Branch: REL_13_STABLE [900429d0c] 2020-08-08 12:31:55 -0400
Branch: REL_12_STABLE [85cb4ec50] 2020-08-08 12:31:55 -0400
Branch: REL_11_STABLE [1fa6eec97] 2020-08-08 12:31:55 -0400
Branch: REL_10_STABLE [d81387da9] 2020-08-08 12:31:55 -0400
Branch: REL9_6_STABLE [55d42c917] 2020-08-08 12:31:55 -0400
Branch: REL9_5_STABLE [ca8e87ea0] 2020-08-08 12:31:55 -0400
-->
<para>
In logical replication walsender, fix failure to send feedback
messages after sending a keepalive message (&Aacute;lvaro Herrera)
</para>
<para>
This is a relatively minor problem when using built-in logical
replication, because the built-in walreceiver will send a feedback
reply (which clears the incorrect state) fairly frequently anyway.
But with some other replication systems, such
as <application>pglogical</application>, it causes significant
performance issues.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d5daae47d] 2020-07-20 13:40:16 -0400
Branch: REL_13_STABLE [2f1f189cf] 2020-07-20 13:40:16 -0400
Branch: REL_12_STABLE [71e561bd4] 2020-07-20 13:40:16 -0400
Branch: REL_11_STABLE [e8de627a3] 2020-07-20 13:40:16 -0400
Branch: REL_10_STABLE [39d6aec19] 2020-07-20 13:40:16 -0400
-->
<para>
Fix firing of column-specific <literal>UPDATE</literal> triggers in
logical replication subscribers (Tom Lane)
</para>
<para>
The code neglected to account for the possibility of column numbers
being different between the publisher and subscriber tables, so that
if those were indeed different, wrong decisions might be made about
which triggers to fire.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [b48df818d] 2020-06-18 16:34:59 +0900
Branch: REL_13_STABLE [43e70addf] 2020-06-18 16:35:29 +0900
Branch: REL_12_STABLE [16f43122d] 2020-06-18 16:35:32 +0900
Branch: REL_11_STABLE [1657e14b5] 2020-06-18 16:35:36 +0900
-->
<para>
Update oldest xmin and LSN values
during <function>pg_replication_slot_advance()</function> (Michael
Paquier)
</para>
<para>
This function previously failed to do that, possibly preventing
resource cleanup (such as removal of no-longer-needed WAL segments)
after manual advancement of a replication slot.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [78e73e875] 2020-07-31 11:43:12 -0400
Branch: REL_13_STABLE [11dce63d6] 2020-07-31 11:43:12 -0400
Branch: REL_12_STABLE [70248d8f5] 2020-07-31 11:43:12 -0400
Branch: REL_11_STABLE [da596fb4b] 2020-07-31 11:43:12 -0400
Branch: REL_10_STABLE [5e724125a] 2020-07-31 11:43:12 -0400
Branch: REL9_6_STABLE [8ab00b9fe] 2020-07-31 11:43:13 -0400
-->
<para>
Fix slow execution of <function>ts_headline()</function> (Tom Lane)
</para>
<para>
The phrase-search fix added in our previous set of minor releases
could cause <function>ts_headline()</function> to take unreasonable
amounts of time for long documents; to make matters worse, the query
was not cancellable within the troublesome loop.
</para>
</listitem>
<listitem>
<!--
Author: Joe Conway <mail@joeconway.com>
Branch: master Release: REL_13_BR [887cdff4d] 2020-05-28 13:19:00 -0400
Branch: REL_12_STABLE [3ccae5445] 2020-05-28 13:19:10 -0400
Branch: REL_11_STABLE [36758c472] 2020-05-28 13:19:16 -0400
Branch: REL_10_STABLE [2cbe3a954] 2020-05-28 13:17:11 -0400
Branch: REL9_6_STABLE [28e2c6eac] 2020-05-28 13:17:20 -0400
Branch: REL9_5_STABLE [bfb9595a7] 2020-05-28 13:17:28 -0400
-->
<para>
Ensure the <function>repeat()</function> function can be interrupted
by query cancel (Joe Conway)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [183926da3] 2020-07-09 16:02:23 -0400
Branch: REL_13_STABLE [601d419b2] 2020-07-09 16:02:23 -0400
Branch: REL_12_STABLE [2564e2d08] 2020-07-09 16:02:23 -0400
Branch: REL_11_STABLE [90b418f81] 2020-07-09 16:02:23 -0400
Branch: REL_10_STABLE [765ad260a] 2020-07-09 16:02:23 -0400
-->
<para>
Fix <function>pg_current_logfile()</function> to not include a
carriage return (<literal>\r</literal>) in its result on Windows
(Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Joe Conway <mail@joeconway.com>
Branch: master [96d1f423f] 2020-07-04 06:26:53 -0400
Branch: REL_13_STABLE [0025c3a2c] 2020-07-04 06:28:21 -0400
Branch: REL_12_STABLE [015e899a7] 2020-07-04 06:28:44 -0400
Branch: REL_11_STABLE [c2cdaf0cb] 2020-07-04 06:29:03 -0400
Branch: master [1d05627fc] 2020-07-04 13:46:31 -0400
Branch: REL_13_STABLE [c536da177] 2020-07-04 13:47:07 -0400
Branch: REL_12_STABLE [b615b2365] 2020-07-04 13:47:21 -0400
Branch: REL_11_STABLE [1243aa9b2] 2020-07-04 13:47:31 -0400
-->
<para>
Ensure that <function>pg_read_file()</function> and related
functions read until EOF is reached (Joe Conway)
</para>
<para>
Previously, if not given a specific data length to read, these
functions would stop at whatever file length was reported
by <function>stat()</function>. That's unhelpful for pipes and
other sorts of virtual files.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [77a3be32f] 2020-06-11 17:38:42 -0400
Branch: REL_13_STABLE [ee788ba99] 2020-06-11 17:38:42 -0400
Branch: REL_12_STABLE [4284e1184] 2020-06-11 17:38:42 -0400
Branch: REL_11_STABLE [49e0a42dd] 2020-06-11 17:38:42 -0400
Branch: REL_10_STABLE [411a4626e] 2020-06-11 17:38:42 -0400
Branch: REL9_6_STABLE [36df06e25] 2020-06-11 17:38:42 -0400
-->
<para>
Fix mis-handling of <literal>NaN</literal> inputs during parallel
aggregation on <type>numeric</type>-type columns (Tom Lane)
</para>
<para>
If some partial aggregation workers found only <literal>NaN</literal>s
while others found only non-<literal>NaN</literal>s, the results
were combined incorrectly, possibly leading to the wrong overall
result (i.e., not <literal>NaN</literal> when it should be).
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_13_BR [a9632830b] 2020-06-04 16:42:23 -0400
Branch: REL_12_STABLE [a958b07bc] 2020-06-04 16:42:08 -0400
Branch: REL_11_STABLE [6490376e5] 2020-06-04 16:42:08 -0400
Branch: REL_10_STABLE [b2c64f571] 2020-06-04 16:42:08 -0400
Branch: REL_10_STABLE [9a9ba4c4d] 2020-06-04 17:57:19 -0400
-->
<para>
Reject time-of-day values greater than 24 hours (Tom Lane)
</para>
<para>
The intention of the datetime input code is to
allow <quote>24:00:00</quote> or
equivalently <quote>23:59:60</quote>, but no larger value.
However, the range check was miscoded so that it would
accept <quote>23:59:60.<replaceable>nnn</replaceable></quote> with
nonzero fractional-second <replaceable>nnn</replaceable>. In
timestamp values this would result in wrapping into the first second
of the next day. In <type>time</type> and <type>timetz</type>
values, the stored value would actually be more than 24 hours,
causing dump/reload failures and possibly other misbehavior.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [63d2ac23b] 2020-06-22 11:46:41 -0400
Branch: REL_13_STABLE [57f8b9913] 2020-06-22 11:46:41 -0400
Branch: REL_12_STABLE [d3d875518] 2020-06-22 11:46:41 -0400
Branch: REL_11_STABLE [35a8e227e] 2020-06-22 11:46:41 -0400
Branch: REL_10_STABLE [6d9f7a094] 2020-06-22 11:46:41 -0400
Branch: REL9_6_STABLE [bd53ea2b2] 2020-06-22 11:46:41 -0400
Branch: REL9_5_STABLE [dda25c599] 2020-06-22 11:46:41 -0400
-->
<para>
Undo double-quoting of index names in <command>EXPLAIN</command>'s
non-text output formats (Tom Lane, Euler Taveira)
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [2a2494229] 2020-07-25 10:20:39 +0530
Branch: REL_13_STABLE [b15367ae3] 2020-07-25 10:31:19 +0530
Branch: REL_12_STABLE [bdaa84e38] 2020-07-25 10:38:46 +0530
Branch: REL_11_STABLE [603c18b7e] 2020-07-25 10:48:09 +0530
Branch: REL_10_STABLE [f963b5bc0] 2020-07-25 10:57:20 +0530
-->
<para>
Fix <command>EXPLAIN</command>'s accounting for resource usage,
particularly buffer accesses, in parallel workers in a plan
using <literal>Gather Merge</literal> nodes
(Jehan-Guillaume de Rorthais)
</para>
</listitem>
<listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [f1fcf2d3b] 2020-07-14 16:55:35 +1200
Branch: REL_13_STABLE [b82730429] 2020-07-14 16:57:41 +1200
Branch: REL_12_STABLE [1231a0b0e] 2020-07-14 17:03:12 +1200
Branch: REL_11_STABLE [d2761b680] 2020-07-14 16:59:57 +1200
Branch: REL_10_STABLE [4e02f88a4] 2020-07-14 17:00:28 +1200
Branch: REL9_6_STABLE [c732df133] 2020-07-14 17:00:57 +1200
Branch: REL9_5_STABLE [e20003fa0] 2020-07-14 17:01:25 +1200
-->
<para>
Fix timing of constraint revalidation in <command>ALTER
TABLE</command> (David Rowley)
</para>
<para>
If <command>ALTER TABLE</command> needs to fully rewrite the table's
contents (for example, due to change of a column's data type) and
also needs to scan the table to re-validate foreign keys
or <literal>CHECK</literal> constraints, it sometimes did things in
the wrong order, leading to odd errors such as <quote>could not read
block 0 in file "base/nnnnn/nnnnn": read only 0 of 8192 bytes</quote>.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_12_STABLE [798b4faef] 2020-07-20 15:54:24 -0400
Branch: REL_11_STABLE [855195a7b] 2020-07-20 15:54:24 -0400
Branch: REL_12_STABLE [b7103bbe3] 2020-07-21 11:40:46 -0400
Branch: REL_11_STABLE [99b0c5da3] 2020-07-21 11:40:47 -0400
Branch: REL_10_STABLE [ae3d40b0c] 2020-07-21 11:40:47 -0400
-->
<para>
Work around incorrect not-null markings for
<structname>pg_subscription</structname>.<structfield>subslotname</structfield>
and <structname>pg_subscription_rel</structname>.<structfield>srsublsn</structfield>
(Tom Lane)
</para>
<para>
The bootstrap catalog data incorrectly marks these two catalog
columns as always non-null. There's no easy way to correct that
mistake in existing installations (though v13 and later will have
the correct markings). The main place that depends on that marking
being correct is JIT-enabled tuple deconstruction, so teach it to
explicitly ignore the marking for these two columns. Also adjust
some C code that accessed <structfield>srsublsn</structfield> without
checking to see if it's null; a crash from that is improbable but
perhaps not impossible.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a742ecf9c] 2020-07-13 20:38:20 -0400
Branch: REL_13_STABLE [0734dbc45] 2020-07-13 20:38:20 -0400
Branch: REL_12_STABLE [d3b642ad9] 2020-07-13 20:38:21 -0400
Branch: REL_11_STABLE [3753df8f8] 2020-07-13 20:38:21 -0400
Branch: REL_10_STABLE [6443cd2e2] 2020-07-13 20:38:21 -0400
Branch: REL9_6_STABLE [dc6bb0994] 2020-07-13 20:38:21 -0400
Branch: REL9_5_STABLE [80d8f6d1d] 2020-07-13 20:38:21 -0400
-->
<para>
Cope with <literal>LATERAL</literal> references in restriction
clauses attached to an un-flattened sub-<literal>SELECT</literal> in
the <literal>FROM</literal> clause (Tom Lane)
</para>
<para>
This oversight could result in assertion failures or crashes at
query execution.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ca5e93f76] 2020-07-03 19:01:21 -0400
Branch: REL_13_STABLE [9233624b1] 2020-07-03 19:01:21 -0400
Branch: REL_12_STABLE [153c14cdd] 2020-07-03 19:01:21 -0400
Branch: REL_11_STABLE [ef799bdd0] 2020-07-03 19:01:21 -0400
Branch: REL_10_STABLE [5144a40f3] 2020-07-03 19:01:22 -0400
Branch: REL9_6_STABLE [69a3fe6e6] 2020-07-03 19:01:22 -0400
Branch: REL9_5_STABLE [d83d59e42] 2020-07-03 19:01:22 -0400
-->
<para>
Avoid believing that a never-analyzed foreign table has zero tuples
(Tom Lane)
</para>
<para>
This primarily affected the planner's estimate of the number of
groups that would be obtained by <literal>GROUP BY</literal>.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [986529ce4] 2020-07-09 20:13:25 -0400
Branch: REL_13_STABLE [c3a79e719] 2020-07-09 20:13:25 -0400
Branch: REL_12_STABLE [ca5001a36] 2020-07-09 20:13:25 -0400
Branch: REL_11_STABLE [907283576] 2020-07-09 20:13:25 -0400
Branch: REL_10_STABLE [40316dfed] 2020-07-09 20:13:24 -0400
-->
<para>
Remove bogus warning about <quote>leftover placeholder tuple</quote>
in BRIN index de-summarization (&Aacute;lvaro Herrera)
</para>
<para>
The case can occur legitimately after a cancelled vacuum, so warning
about it is overly noisy.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f7b5988cc] 2020-07-03 17:01:34 -0400
Branch: REL_13_STABLE [cfe89f5e6] 2020-07-03 17:01:34 -0400
Branch: REL_12_STABLE [8b83e0160] 2020-07-03 17:01:34 -0400
Branch: REL_11_STABLE [79ed1d99d] 2020-07-03 17:01:34 -0400
Author: Magnus Hagander <magnus@hagander.net>
Branch: master [ecd9e9f0b] 2020-07-03 15:09:06 +0200
Branch: REL_13_STABLE [1d94c3965] 2020-07-03 15:10:12 +0200
Branch: REL_12_STABLE [28a862e9d] 2020-07-03 15:10:33 +0200
Branch: REL_11_STABLE [4aa02d072] 2020-07-03 15:10:41 +0200
-->
<para>
Fix selection of tablespaces for <quote>shared fileset</quote>
temporary files (Magnus Hagander, Tom Lane)
</para>
<para>
If <varname>temp_tablespaces</varname> is empty or explicitly names
the database's primary tablespace, such files got placed into
the <literal>pg_default</literal> tablespace rather than the
database's primary tablespace as expected.
</para>
</listitem>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [a44dd932f] 2020-06-20 17:34:51 +0300
Branch: REL_13_STABLE [39aafc88c] 2020-06-20 18:14:51 +0300
Branch: REL_12_STABLE [396a44a01] 2020-06-20 17:35:55 +0300
Branch: REL_11_STABLE [3f88e2d78] 2020-06-20 17:35:59 +0300
-->
<para>
Fix corner-case error in masking of SP-GiST index pages during WAL
consistency checking (Alexander Korotkov)
</para>
<para>
This could cause false failure reports
when <varname>wal_consistency_checking</varname> is enabled.
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [7897e3bb9] 2020-06-16 16:59:07 +1200
Branch: REL_13_STABLE [3e0b08c40] 2020-06-16 17:00:06 +1200
Branch: REL_12_STABLE [28ee12669] 2020-06-16 17:00:21 +1200
Branch: REL_11_STABLE [9c14d6024] 2020-06-16 17:00:37 +1200
Branch: REL_10_STABLE [95647a1c7] 2020-06-16 17:00:53 +1200
Branch: REL9_6_STABLE [02b71f06b] 2020-06-16 17:01:07 +1200
Branch: REL9_5_STABLE [89020a92f] 2020-06-16 17:01:22 +1200
Branch: master [42dee8b8e] 2020-07-23 21:10:49 +1200
Branch: REL_13_STABLE [6b366190d] 2020-07-23 21:15:01 +1200
Branch: REL_12_STABLE [8bf4e69a7] 2020-07-23 21:17:47 +1200
Branch: REL_11_STABLE [028f0c3a8] 2020-07-23 21:18:02 +1200
Branch: REL_10_STABLE [fac4145bf] 2020-07-23 21:18:13 +1200
Branch: REL9_6_STABLE [47adb2488] 2020-07-23 21:18:25 +1200
Branch: REL9_5_STABLE [3725c8ce4] 2020-07-23 21:18:34 +1200
-->
<para>
Improve error handling in the server's <filename>buffile</filename>
module (Thomas Munro)
</para>
<para>
Fix some cases where I/O errors were indistinguishable from reaching
EOF, or were not reported at all. Also add details such as block
numbers and byte counts where appropriate.
</para>
</listitem>
<listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [5940ffb22] 2020-06-11 10:09:47 -0700
Branch: REL_13_STABLE [6df7105e5] 2020-06-11 10:09:45 -0700
Branch: REL_12_STABLE [e620a38c2] 2020-06-11 10:09:43 -0700
Branch: REL_11_STABLE [dd616f2ec] 2020-06-11 10:09:40 -0700
Branch: REL_10_STABLE [19a6e1bc3] 2020-06-11 10:09:37 -0700
Branch: REL9_6_STABLE [e81dc2b7e] 2020-06-11 10:09:35 -0700
Branch: REL9_5_STABLE [c05f6b354] 2020-06-11 10:09:32 -0700
-->
<para>
Fix conflict-checking anomalies in <literal>SERIALIZABLE</literal>
isolation mode (Peter Geoghegan)
</para>
<para>
If a concurrently-inserted tuple was updated by a different
concurrent transaction, and neither tuple version was visible to the
current transaction's snapshot, serialization conflict checking
could draw the wrong conclusions about whether the tuple was relevant
to the results of the current transaction. This could allow a
serializable transaction to commit when it should have failed with a
serialization error.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master Release: REL_13_BR [242dfcbaf] 2020-05-15 16:50:34 -0400
Branch: REL_12_STABLE [1d84751c6] 2020-05-15 16:50:34 -0400
Branch: REL_11_STABLE [37b5c5fde] 2020-05-15 16:50:34 -0400
Branch: REL_10_STABLE [09f2752b0] 2020-05-15 16:50:34 -0400
Branch: REL9_6_STABLE [4649eb919] 2020-05-15 16:50:34 -0400
Branch: REL9_5_STABLE [0a319699d] 2020-05-15 16:50:34 -0400
-->
<para>
Avoid repeated marking of dead btree index entries as dead (Masahiko
Sawada)
</para>
<para>
While functionally harmless, this led to useless WAL traffic when
checksums are enabled or <varname>wal_log_hints</varname> is on.
</para>
</listitem>
<listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master Release: REL_13_BR [303640199] 2019-12-19 09:06:54 -0500
Branch: REL_12_STABLE [bcbc27251] 2020-08-06 13:58:23 -0400
Branch: REL_11_STABLE [f7013683d] 2020-08-06 14:06:24 -0400
Branch: master Release: REL_13_BR [f05798014] 2020-04-26 13:48:33 +0200
Branch: REL_12_STABLE [7c78040f6] 2020-08-06 14:55:00 -0400
Branch: REL_11_STABLE [495a9b1fb] 2020-08-06 15:01:55 -0400
-->
<para>
Avoid trouble during cleanup of a non-exclusive backup when JIT
compilation has been activated during the backup (Robert Haas)
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [57cb80630] 2020-06-08 13:57:24 +1200
Branch: REL_13_STABLE [acefa2cca] 2020-06-08 13:58:10 +1200
Branch: REL_12_STABLE [72766ad63] 2020-06-08 13:58:35 +1200
Branch: REL_11_STABLE [48eb6a3c8] 2020-06-08 13:59:57 +1200
Branch: REL_10_STABLE [fd11b842e] 2020-06-08 14:01:07 +1200
Branch: REL9_6_STABLE [644cac32a] 2020-06-08 14:01:51 +1200
Branch: REL9_5_STABLE [09dc17486] 2020-06-08 14:02:20 +1200
-->
<para>
Fix failure of some code paths to acquire the correct lock before
modifying <filename>pg_control</filename> (Nathan Bossart, Fujii
Masao)
</para>
<para>
This oversight could allow <filename>pg_control</filename> to be
written out with an inconsistent checksum, possibly causing trouble
later, including inability to restart the database if it crashed
before the next <filename>pg_control</filename> update.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_13_BR [ce1c5b9ae] 2020-06-01 14:41:18 +0900
Branch: REL_12_STABLE [894041eb2] 2020-06-01 14:41:25 +0900
Branch: REL_11_STABLE [8bc74490d] 2020-06-01 14:41:32 +0900
Branch: REL_10_STABLE [a36f21620] 2020-06-01 14:41:37 +0900
Branch: REL9_6_STABLE [e2fa9732f] 2020-06-01 14:41:42 +0900
Branch: REL9_5_STABLE [a8c6eb5b4] 2020-06-01 14:41:46 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_13_BR [e786be5fc] 2020-06-01 10:32:06 +0900
Branch: REL_12_STABLE [95e389b3c] 2020-06-01 10:32:53 +0900
-->
<para>
Fix errors in <function>currtid()</function>
and <function>currtid2()</function> (Michael Paquier)
</para>
<para>
These functions (which are undocumented and used only by ancient
versions of the ODBC driver) contained coding errors that could
result in crashes, or in confusing error messages such as <quote>could
not open file</quote> when applied to a relation having no storage.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_13_BR [c1669fd58] 2020-06-04 10:17:49 +0900
Branch: REL_12_STABLE [03aa25b6e] 2020-06-04 10:18:02 +0900
Branch: REL_11_STABLE [b41a85f53] 2020-06-04 10:18:06 +0900
Branch: REL_10_STABLE [5ed8b4a98] 2020-06-04 10:18:11 +0900
Branch: REL9_6_STABLE [e7a134b58] 2020-06-04 10:18:17 +0900
Branch: REL9_5_STABLE [4a9809e34] 2020-06-04 10:18:27 +0900
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_13_BR [f88bd3139] 2020-06-03 12:36:23 -0400
Branch: REL_12_STABLE [3d474a079] 2020-06-03 12:36:24 -0400
Branch: REL_11_STABLE [7a8cb4a61] 2020-06-03 12:36:00 -0400
Branch: REL_10_STABLE [0c735c686] 2020-06-03 12:36:00 -0400
-->
<para>
Avoid calling <function>elog()</function>
or <function>palloc()</function> while holding a spinlock (Michael
Paquier, Tom Lane)
</para>
<para>
Logic associated with replication slots had several violations of
this coding rule. While the odds of trouble are quite low, an error
in the called function would lead to a stuck spinlock.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_13_BR [7ccb2f54d] 2020-05-16 18:15:18 +0900
Branch: REL_12_STABLE [b4ded2f22] 2020-05-16 18:16:31 +0900
Branch: REL_11_STABLE [70ae82b9b] 2020-05-16 18:16:37 +0900
Branch: REL_10_STABLE [3acb30b49] 2020-05-16 18:16:41 +0900
-->
<para>
Fix assertion in logical replication subscriber to allow use
of <literal>REPLICA IDENTITY FULL</literal> (Euler Taveira)
</para>
<para>
This was just an incorrect assertion, so it has no impact on
standard production builds.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [ae3259c55] 2020-06-19 16:46:07 -0400
Branch: REL_13_STABLE [e74559c97] 2020-06-19 16:46:07 -0400
Branch: REL_12_STABLE [5b52008a6] 2020-06-19 16:46:07 -0400
Branch: REL_11_STABLE [2e155d90d] 2020-06-19 16:46:07 -0400
Branch: REL_10_STABLE [411febd53] 2020-06-19 16:46:07 -0400
Branch: REL9_6_STABLE [83762d0a9] 2020-06-19 16:46:07 -0400
Branch: REL9_5_STABLE [bbbce94dc] 2020-06-19 16:46:06 -0400
-->
<para>
Report out-of-disk-space errors properly
in <application>pg_dump</application>
and <application>pg_basebackup</application> (Justin Pryzby, Tom
Lane, &Aacute;lvaro Herrera)
</para>
<para>
Some code paths could produce silly reports like <quote>could not
write file: Success</quote>.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ea9125304] 2020-07-11 13:36:50 -0400
Branch: REL_13_STABLE [bc9aaac1a] 2020-07-11 13:36:50 -0400
Branch: REL_12_STABLE [5fea14f4b] 2020-07-11 13:36:50 -0400
Branch: REL_11_STABLE [4fdc559c8] 2020-07-11 13:36:50 -0400
Branch: REL_10_STABLE [2d43c3057] 2020-07-11 13:36:51 -0400
Branch: REL9_6_STABLE [303322c5a] 2020-07-11 13:36:51 -0400
Branch: REL9_5_STABLE [db820b9a9] 2020-07-11 13:36:51 -0400
-->
<para>
Fix parallel restore of tables having both table-level privileges
and per-column privileges (Tom Lane)
</para>
<para>
The table-level privilege grants have to be applied first, but a
parallel restore did not reliably order them that way; this could
lead to <quote>tuple concurrently updated</quote> errors, or to
disappearance of some per-column privilege grants. The fix for this
is to include dependency links between such entries in the archive
file, meaning that a new dump has to be taken with a
corrected <application>pg_dump</application> to ensure that the
problem will not recur.
</para>
</listitem>
<listitem>
<!--
Author: Bruce Momjian <bruce@momjian.us>
Branch: master [3f5863e15] 2020-06-15 20:59:40 -0400
Branch: REL_13_STABLE [a2c72851a] 2020-06-15 20:59:40 -0400
Branch: REL_12_STABLE [8e933596c] 2020-06-15 20:59:40 -0400
Branch: REL_11_STABLE [aeb785c0f] 2020-06-15 20:59:40 -0400
Branch: REL_10_STABLE [9170da96d] 2020-06-15 20:59:40 -0400
Branch: REL9_6_STABLE [5c1bfd627] 2020-06-15 20:59:40 -0400
Branch: REL9_5_STABLE [39c698cff] 2020-06-15 20:59:40 -0400
-->
<para>
Ensure that <application>pg_upgrade</application> runs
with <varname>vacuum_defer_cleanup_age</varname> set to zero in the
target cluster (Bruce Momjian)
</para>
<para>
If the target cluster's configuration has been modified to
set <varname>vacuum_defer_cleanup_age</varname> to a nonzero value,
that prevented freezing of the system catalogs from working properly,
which caused the upgrade to fail in confusing ways. Ensure that any
such setting is overridden for the duration of the upgrade.
</para>
</listitem>
<listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master Release: REL_13_BR [cee9cadb5] 2020-05-13 20:42:09 -0700
Branch: REL_12_STABLE [73a5c0d81] 2020-05-13 20:42:24 -0700
Branch: REL_11_STABLE [a26789452] 2020-05-13 20:42:37 -0700
Branch: REL_10_STABLE [970ed4493] 2020-05-13 20:42:42 -0700
Branch: REL9_6_STABLE [1ab5b672e] 2020-05-13 20:42:46 -0700
Branch: REL9_5_STABLE [595b4115c] 2020-05-13 20:42:49 -0700
Author: Noah Misch <noah@leadboat.com>
Branch: master Release: REL_13_BR [8222a9d9a] 2020-05-13 20:42:09 -0700
Branch: REL_12_STABLE [7130be8aa] 2020-05-13 20:42:23 -0700
Branch: REL_11_STABLE [357012e17] 2020-05-13 20:42:34 -0700
Branch: REL_10_STABLE [a28db2081] 2020-05-13 20:42:42 -0700
-->
<para>
Fix <application>pg_recvlogical</application> to drain pending
messages before exiting (Noah Misch)
</para>
<para>
Without this, the replication sender might detect a send failure and
exit without making the expected final update to the replication
slot's LSN position. That led to re-transmitting data after the
next connection. It was also possible to miss error messages sent
after the last data that <application>pg_recvlogical</application>
wants to consume.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [1d09fb1f0] 2020-07-15 15:17:23 +0900
Branch: REL_13_STABLE [5f89bb4cf] 2020-07-15 15:17:32 +0900
Branch: REL_12_STABLE [92927477f] 2020-07-15 15:17:36 +0900
Branch: REL_11_STABLE [c6d33d144] 2020-07-15 15:17:44 +0900
Branch: REL_10_STABLE [23924feca] 2020-07-15 15:17:49 +0900
Branch: REL9_6_STABLE [14fe80413] 2020-07-15 15:17:55 +0900
Branch: REL9_5_STABLE [18ec25412] 2020-07-15 15:18:01 +0900
-->
<para>
Fix <application>pg_rewind</application>'s handling of just-deleted
files in the source data directory (Justin Pryzby, Michael Paquier)
</para>
<para>
When working with an on-line source database, concurrent file
deletions are possible, but <application>pg_rewind</application>
would get confused if deletion happened between seeing a file's
directory entry and examining it with <function>stat()</function>.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [932f9fb50] 2020-07-16 15:52:37 +0900
Branch: REL_13_STABLE [beebbb39d] 2020-07-16 15:52:54 +0900
Branch: REL_12_STABLE [cd113a0b4] 2020-07-16 15:52:58 +0900
Branch: REL_11_STABLE [de559c2b0] 2020-07-16 15:53:01 +0900
Branch: REL_10_STABLE [800ec48f5] 2020-07-16 15:53:04 +0900
Branch: REL9_6_STABLE [a452b239e] 2020-07-16 15:53:09 +0900
Branch: REL9_5_STABLE [ab7ce97ec] 2020-07-16 15:53:12 +0900
-->
<para>
Make <application>pg_test_fsync</application> use binary I/O mode on
Windows (Michael Paquier)
</para>
<para>
Previously it wrote the test file in text mode, which is not an
accurate reflection of <productname>PostgreSQL</productname>'s
actual usage.
</para>
</listitem>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master Release: REL_13_BR [34dae902c] 2020-05-14 12:44:44 +0300
Branch: REL_12_STABLE [ae1f9b0a9] 2020-05-14 12:46:08 +0300
Branch: REL_11_STABLE [b9a45d8db] 2020-05-14 12:46:15 +0300
-->
<para>
Fix <filename>contrib/amcheck</filename> to not complain about
deleted index pages that are empty (Alexander Korotkov)
</para>
<para>
This state of affairs is normal during WAL replay.
</para>
</listitem>
<listitem>
<!--
Author: Joe Conway <mail@joeconway.com>
Branch: master Release: REL_13_BR [9003b76e1] 2020-05-28 13:44:54 -0400
Branch: REL_12_STABLE [e8eb48595] 2020-05-28 13:44:59 -0400
Branch: REL_11_STABLE [49a00e07c] 2020-05-28 13:45:02 -0400
Branch: REL_10_STABLE [43d3d7318] 2020-05-28 13:45:06 -0400
Branch: REL9_6_STABLE [43d7934a3] 2020-05-28 13:45:11 -0400
Branch: REL9_5_STABLE [f140d9b6e] 2020-05-28 13:45:15 -0400
-->
<para>
Fix failure to initialize local state correctly
in <filename>contrib/dblink</filename> (Joe Conway)
</para>
<para>
With the right combination of circumstances, this could lead to
<function>dblink_close()</function> issuing an unexpected
remote <command>COMMIT</command>.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b9b610577] 2020-07-23 17:20:01 -0400
Branch: REL_13_STABLE [7dab4569d] 2020-07-23 17:20:01 -0400
Branch: REL_12_STABLE [3d4a77815] 2020-07-23 17:20:02 -0400
Branch: REL_11_STABLE [475c69c97] 2020-07-23 17:20:03 -0400
Branch: REL_10_STABLE [d8ec3b126] 2020-07-23 17:20:03 -0400
Branch: REL9_6_STABLE [ccf964a80] 2020-07-23 17:20:04 -0400
Branch: REL9_5_STABLE [d0519e9fe] 2020-07-23 17:20:04 -0400
-->
<para>
Fix <filename>contrib/pgcrypto</filename>'s misuse
of <function>deflate()</function> (Tom Lane)
</para>
<para>
The <function>pgp_sym_encrypt</function> functions could produce
incorrect compressed data due to mishandling
of <application>zlib</application>'s API requirements. We have no
reports of this error manifesting with
stock <application>zlib</application>, but it can be seen when using
IBM's <application>zlibNX</application> implementation.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [a3ab7a707] 2020-07-27 15:58:32 +0900
Branch: REL_13_STABLE [0caf1fc6e] 2020-07-27 15:58:54 +0900
Branch: REL_12_STABLE [5bd087eb5] 2020-07-27 15:58:59 +0900
Branch: REL_11_STABLE [202fc4ca5] 2020-07-27 15:59:03 +0900
Branch: REL_10_STABLE [9729f9979] 2020-07-27 15:59:07 +0900
Branch: REL9_6_STABLE [8a60f541f] 2020-07-27 15:59:13 +0900
Branch: REL9_5_STABLE [aaa132a65] 2020-07-27 15:59:22 +0900
Branch: REL_11_STABLE [1785ac8ad] 2020-08-02 11:00:12 -0400
Branch: REL_10_STABLE [e1b4135cf] 2020-08-02 11:00:12 -0400
-->
<para>
Fix corner case in decompression logic
in <filename>contrib/pgcrypto</filename>'s
<function>pgp_sym_decrypt</function> functions (Kyotaro Horiguchi,
Michael Paquier)
</para>
<para>
A compressed stream can validly end with an empty packet, but the
decompressor failed to handle this and would complain about corrupt
data.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_11_STABLE [c6d43ffab] 2020-07-15 22:05:12 -0400
Branch: REL_10_STABLE [0140dec18] 2020-07-15 22:05:12 -0400
Branch: REL9_6_STABLE [9e043d93c] 2020-07-15 22:05:13 -0400
Branch: REL9_5_STABLE [d61dcccaf] 2020-07-15 22:05:13 -0400
-->
<para>
Use POSIX-standard <function>strsignal()</function> in place of the
BSD-ish <literal>sys_siglist[]</literal> (Tom Lane)
</para>
<para>
This avoids build failures with very recent versions
of <application>glibc</application>.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_13_BR [a16915545] 2020-05-14 09:24:33 +0530
Branch: REL_12_STABLE [98171e59a] 2020-05-14 09:34:46 +0530
Branch: REL_11_STABLE [1fbfc3d8a] 2020-05-14 09:39:04 +0530
Branch: REL_10_STABLE [33b772801] 2020-05-14 09:44:21 +0530
Branch: REL9_6_STABLE [a1466e194] 2020-05-14 09:50:10 +0530
Branch: REL9_5_STABLE [650952aeb] 2020-05-14 09:55:04 +0530
-->
<para>
Support building our NLS code with Microsoft Visual Studio 2015 or
later (Juan Jos&eacute; Santamar&iacute;a Flecha, Davinder Singh,
Amit Kapila)
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_13_BR [d2a995990] 2020-05-21 14:41:15 +0900
Branch: REL_12_STABLE [089baec6f] 2020-05-21 14:41:30 +0900
Branch: REL_11_STABLE [bb24af50d] 2020-05-21 14:41:33 +0900
Branch: REL_10_STABLE [8dfc7d888] 2020-05-21 14:41:36 +0900
Branch: REL9_6_STABLE [57dc672c2] 2020-05-21 14:41:40 +0900
Branch: REL9_5_STABLE [8de137017] 2020-05-21 14:41:43 +0900
-->
<para>
Avoid possible failure of our MSVC install script when there is a
file named <filename>configure</filename> several levels above the
source code tree (Arnold M&uuml;ller)
</para>
<para>
This could confuse some logic that looked
for <filename>configure</filename> to identify the top level of the
source tree.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-11-8">
<title>Release 11.8</title>