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 14.3, 13.7, 12.11, 11.16, 10.21.

This commit is contained in:
Tom Lane 2022-05-08 12:36:38 -04:00
parent 4caa85e4f3
commit fdaaba1539
1 changed files with 948 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

948
doc/src/sgml/release-13.sgml
View File

@ -1,6 +1,954 @@
<!-- doc/src/sgml/release-13.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-13-7">
<title>Release 13.7</title>
<formalpara>
<title>Release date:</title>
<para>2022-05-12</para>
</formalpara>
<para>
This release contains a variety of fixes from 13.6.
For information about new features in major release 13, see
<xref linkend="release-13"/>.
</para>
<sect2>
<title>Migration to Version 13.7</title>
<para>
A dump/restore is not required for those running 13.X.
</para>
<para>
However, if you have any GiST indexes on columns of type
<type>ltree</type> (supplied by the <filename>contrib/ltree</filename>
extension), you should re-index them after updating.
See the first changelog entry below.
</para>
<para>
Also, if you are upgrading from a version earlier than 13.6,
see <xref linkend="release-13-6"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [7e74aafc4] 2022-03-16 11:41:18 +0300
Branch: REL_14_STABLE [7d30f59da] 2022-03-16 11:41:30 +0300
Branch: REL_13_STABLE [bad202c61] 2022-03-16 11:41:34 +0300
-->
<para>
Fix default signature length for <literal>gist_ltree_ops</literal>
indexes (Tomas Vondra, Alexander Korotkov)
</para>
<para>
The default signature length (hash size) for GiST indexes
on <type>ltree</type> columns was accidentally changed while
upgrading that operator class to support operator class parameters.
If any operations had been done on such an index without first
upgrading the <literal>ltree</literal> extension to version 1.2,
they were done assuming that the signature length was 28 bytes
rather than the intended 8. This means it is very likely that such
indexes are now corrupt. For safety we recommend re-indexing all
GiST indexes on <type>ltree</type> columns after installing this
update. (Note that GiST indexes on <type>ltree[]</type>
columns, that is arrays of <type>ltree</type>, are not affected.)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ec62cb0aa] 2022-03-17 18:18:05 -0400
Branch: REL_14_STABLE [1d072bd20] 2022-03-17 18:18:05 -0400
Branch: REL_13_STABLE [5e144cc89] 2022-03-17 18:18:05 -0400
Branch: REL_12_STABLE [1f5ef5ae0] 2022-03-17 18:18:05 -0400
Branch: REL_11_STABLE [13b54d1e0] 2022-03-17 18:18:05 -0400
Branch: REL_10_STABLE [205214c8b] 2022-03-17 18:18:05 -0400
-->
<para>
Stop using query-provided column aliases for the columns of
whole-row variables that refer to plain tables (Tom Lane)
</para>
<para>
The column names in tuples produced by a whole-row variable (such
as <literal>tbl.*</literal> in contexts other than the top level of
a <literal>SELECT</literal> list) are now always those of the
associated named composite type, if there is one. We'd previously
attempted to make them track any column aliases that had been
applied to the <literal>FROM</literal> entry the variable refers to.
But that's semantically dubious, because really then the output of
the variable is not at all of the composite type it claims to be.
Previous attempts to deal with that inconsistency had bad results up
to and including storing unreadable data on disk, so just give up on
the whole idea.
</para>
<para>
In cases where it's important to be able to relabel such columns,
a workaround is to introduce an extra level of
sub-<literal>SELECT</literal>, so that the whole-row variable is
referring to the sub-<literal>SELECT</literal>'s output and not to a
plain table. Then the variable is of type <type>record</type>
to begin with and there's no issue.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [eafdf9de0] 2022-04-20 18:08:23 -0400
Branch: REL_14_STABLE [e34632947] 2022-04-20 18:08:24 -0400
Branch: REL_13_STABLE [8275ba773] 2022-04-20 18:08:15 -0400
Branch: REL_12_STABLE [33fe55c06] 2022-04-20 18:08:15 -0400
Branch: REL_11_STABLE [e7adbd282] 2022-04-20 18:08:15 -0400
Branch: REL_10_STABLE [a1e4782a0] 2022-04-20 18:08:15 -0400
-->
<para>
Disallow infinite endpoints in the timestamp variants
of <function>generate_series()</function> (Tom Lane)
</para>
<para>
Previously, such a call would run until canceled (or
out-of-disk-space). The numeric variant already threw an error for
an infinite endpoint value, so do likewise for timestamps.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [068739fb4] 2022-03-18 16:01:42 -0400
Branch: REL_14_STABLE [ae8ec7feb] 2022-03-18 16:01:42 -0400
Branch: REL_13_STABLE [88ae77588] 2022-03-18 16:01:42 -0400
Branch: REL_12_STABLE [840729fd1] 2022-03-18 16:01:42 -0400
Branch: REL_11_STABLE [84f3ecdaa] 2022-03-18 16:01:42 -0400
Branch: REL_10_STABLE [e6fd4a3da] 2022-03-18 16:01:42 -0400
-->
<para>
Fix incorrect output for types <type>timestamptz</type>
and <type>timetz</type> in <function>table_to_xmlschema()</function>
and allied functions (Renan Soares Lopes)
</para>
<para>
The xmlschema output for these types included a malformed regular
expression.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2591ee8ec] 2022-03-21 17:44:29 -0400
Branch: REL_14_STABLE [48b6035f0] 2022-03-21 17:44:29 -0400
Branch: REL_13_STABLE [dfefe38fb] 2022-03-21 17:44:29 -0400
Branch: REL_12_STABLE [69c88e2fb] 2022-03-21 17:44:29 -0400
Branch: REL_11_STABLE [5de244196] 2022-03-21 17:44:29 -0400
Branch: REL_10_STABLE [2afa031ac] 2022-03-21 17:44:29 -0400
-->
<para>
Fix planner errors for <function>GROUPING()</function> constructs
that reference outer query levels (Richard Guo, Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e5691cc91] 2022-02-11 15:24:02 -0500
Branch: REL_14_STABLE [277e744ae] 2022-02-11 15:23:52 -0500
Branch: REL_13_STABLE [0778b24ce] 2022-02-11 15:23:52 -0500
Branch: REL_12_STABLE [32e801676] 2022-02-11 15:23:52 -0500
Branch: REL_11_STABLE [14ee565f3] 2022-02-11 15:23:52 -0500
Branch: REL_10_STABLE [b6f869bee] 2022-02-11 15:23:52 -0500
-->
<para>
Fix plan generation for index-only scans on indexes with
both returnable and non-returnable columns (Tom Lane)
</para>
<para>
The previous coding could try to read non-returnable columns
in addition to the returnable ones. This was fairly harmless
because it didn't actually do anything with the bogus values,
but it fell foul of a recently-added error check that rejected
such a plan.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7b7ed046c] 2022-04-13 13:35:07 -0400
Branch: REL_14_STABLE [c590e514a] 2022-04-13 13:35:02 -0400
Branch: REL_13_STABLE [44096c31e] 2022-04-13 13:35:02 -0400
Branch: REL_12_STABLE [e0ed20d0b] 2022-04-13 13:35:02 -0400
-->
<para>
Avoid accessing a no-longer-pinned shared buffer while attempting
to lock an outdated tuple during EvalPlanQual (Tom Lane)
</para>
<para>
The code would touch the buffer a couple more times after releasing
its pin. In theory another process could recycle the buffer (or
more likely, try to defragment its free space) as soon as the pin is
gone, probably leading to failure to find the newer version of the
tuple.
</para>
</listitem>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [3f74daa8d] 2022-02-14 04:17:04 +0300
Branch: REL_14_STABLE [c76665edc] 2022-02-14 03:32:31 +0300
Branch: REL_13_STABLE [ac2303aa0] 2022-02-14 03:32:34 +0300
Branch: REL_12_STABLE [7a12a9e3c] 2022-02-14 03:32:39 +0300
Branch: REL_11_STABLE [0d554775b] 2022-02-14 04:04:19 +0300
Branch: REL_10_STABLE [2e9033a54] 2022-02-14 04:04:28 +0300
-->
<para>
Fix query-lifespan memory leak in an IndexScan node that is
performing reordering (Aliaksandr Kalenik)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [344a225cb] 2022-04-19 23:03:59 -0400
Branch: REL_14_STABLE [08a9e7a8c] 2022-04-19 23:03:59 -0400
Branch: REL_13_STABLE [f583633bc] 2022-04-19 23:03:59 -0400
Branch: REL_12_STABLE [481a99811] 2022-04-19 23:03:59 -0400
Branch: REL_11_STABLE [9130f8cbb] 2022-04-19 23:03:59 -0400
Branch: REL_10_STABLE [409bcfda6] 2022-04-19 23:03:59 -0400
-->
<para>
Fix <command>ALTER FUNCTION</command> to support changing a
function's parallelism property and
its <literal>SET</literal>-variable list in the same command (Tom
Lane)
</para>
<para>
The parallelism property change was lost if the same command also
updated the function's <literal>SET</literal> clause.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [36d4efe77] 2022-04-18 12:16:45 -0400
Branch: REL_14_STABLE [e805735a8] 2022-04-18 12:16:45 -0400
Branch: REL_13_STABLE [69cefb3fb] 2022-04-18 12:16:45 -0400
Branch: REL_12_STABLE [0795da869] 2022-04-18 12:16:45 -0400
-->
<para>
Fix bogus errors from attempts to alter system columns of tables
(Tom Lane)
</para>
<para>
The system should just tell you that you can't do it, but sometimes
it would report <quote>no owned sequence found</quote> instead.
</para>
</listitem>
<listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [8ab0ebb9a] 2022-04-20 17:17:43 -0700
Branch: REL_14_STABLE [e4521841a] 2022-04-20 17:17:41 -0700
Branch: REL_13_STABLE [1272630a2] 2022-04-20 17:17:39 -0700
Branch: REL_12_STABLE [5487585e3] 2022-04-20 17:17:37 -0700
Branch: REL_11_STABLE [adb2d84fc] 2022-04-20 17:17:35 -0700
Branch: REL_10_STABLE [a903895b3] 2022-04-20 17:17:33 -0700
-->
<para>
Fix mis-sorting of table rows when <command>CLUSTER</command>ing
using an index whose leading key is an expression (Peter Geoghegan,
Thomas Munro)
</para>
<para>
The table would be rebuilt with the correct data, but in an order
having little to do with the index order.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7b6ec8653] 2022-03-21 12:22:13 -0400
Branch: REL_14_STABLE [05ccf974c] 2022-03-21 12:22:13 -0400
Branch: REL_13_STABLE [2241e5ced] 2022-03-21 12:22:13 -0400
Branch: REL_12_STABLE [d8d378d51] 2022-03-21 12:22:13 -0400
Branch: REL_11_STABLE [b8ae17fd9] 2022-03-21 12:22:13 -0400
-->
<para>
Fix risk of deadlock failures while dropping a partitioned index
(Jimmy Yih, Gaurab Dey, Tom Lane)
</para>
<para>
Ensure that the required table and index locks are taken in the
standard order (parents before children, tables before indexes).
The previous coding for <command>DROP INDEX</command> did it
differently, and so could deadlock against concurrent queries taking
these locks in the standard order.
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [46d9bfb0a] 2022-03-16 17:20:24 +1300
Branch: REL_14_STABLE [26e007939] 2022-03-16 17:20:50 +1300
Branch: REL_13_STABLE [51e760e5a] 2022-03-16 17:21:19 +1300
Branch: REL_12_STABLE [c918f07dd] 2022-03-16 17:21:46 +1300
Branch: REL_11_STABLE [ca522c60a] 2022-03-16 17:38:55 +1300
Branch: REL_10_STABLE [fe197872c] 2022-03-16 17:41:31 +1300
-->
<para>
Fix race condition between <command>DROP TABLESPACE</command> and
checkpointing (Nathan Bossart)
</para>
<para>
The checkpoint forced by <command>DROP TABLESPACE</command> could
sometimes fail to remove all dead files from the tablespace's
directory, leading to a bogus <quote>tablespace is not empty</quote>
error.
</para>
</listitem>
<listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master [412ad7a55] 2022-03-24 14:52:28 -0400
Branch: REL_14_STABLE [bbace5697] 2022-03-24 14:32:48 -0400
Branch: REL_13_STABLE [1ce14b6b2] 2022-03-24 14:36:06 -0400
Branch: REL_12_STABLE [3821d66a7] 2022-03-24 14:38:51 -0400
Branch: REL_11_STABLE [118f1a332] 2022-03-24 14:49:08 -0400
Branch: REL_10_STABLE [57f618310] 2022-03-24 14:50:06 -0400
Author: Robert Haas <rhaas@postgresql.org>
Branch: REL_14_STABLE [10520f434] 2022-04-14 11:10:07 -0400
Branch: REL_13_STABLE [d18c913b7] 2022-04-14 11:10:11 -0400
Branch: REL_12_STABLE [68e605b9e] 2022-04-14 11:10:13 -0400
Branch: REL_11_STABLE [6270ee445] 2022-04-14 11:10:16 -0400
Branch: REL_10_STABLE [48b398943] 2022-04-14 11:10:18 -0400
-->
<para>
Fix possible trouble in crash recovery after
a <command>TRUNCATE</command> command that overlaps a checkpoint
(Kyotaro Horiguchi, Heikki Linnakangas, Robert Haas)
</para>
<para>
<command>TRUNCATE</command> must ensure that the table's disk file
is truncated before the checkpoint is allowed to complete.
Otherwise, replay starting from that checkpoint might find
unexpected data in the supposedly-removed pages, possibly causing
replay failure.
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [7c38ef2a5] 2022-02-21 08:57:34 -0800
Branch: REL_14_STABLE [7bbfe5994] 2022-02-21 09:57:05 -0800
Branch: REL_13_STABLE [c2551483e] 2022-02-21 08:59:30 -0800
Branch: REL_12_STABLE [0033fc63f] 2022-02-21 08:59:32 -0800
Branch: REL_11_STABLE [3faa21bb7] 2022-02-21 08:59:34 -0800
Branch: REL_10_STABLE [cebc54b90] 2022-02-21 08:59:36 -0800
-->
<para>
Fix unsafe toast-data accesses during temporary object cleanup
(Andres Freund)
</para>
<para>
Temporary-object deletion during server process exit could fail
with <quote>FATAL: cannot fetch toast data without an active
snapshot</quote>. This was usually harmless since the next use of
that temporary schema would clean up successfully.
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [3390ef1b7] 2022-03-16 15:35:16 +1300
Branch: REL_14_STABLE [1396b5c6e] 2022-03-16 15:35:42 +1300
Branch: REL_13_STABLE [cfdb303be] 2022-03-16 15:37:15 +1300
Branch: REL_12_STABLE [368ffdeee] 2022-03-16 15:38:13 +1300
-->
<para>
Improve wait logic in RegisterSyncRequest (Thomas Munro)
</para>
<para>
If we run out of space in the checkpointer sync request queue (which
is hopefully rare on real systems, but is common when testing with a
very small buffer pool), we wait for it to drain. While waiting, we
should report that as a wait event so that users know what is going
on, and also watch for postmaster death, since otherwise the loop might
never terminate if the checkpointer has already exited.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [9d92582ab] 2022-03-23 18:22:10 +0100
Branch: REL_14_STABLE [caaeb88ff] 2022-03-23 18:22:10 +0100
Branch: REL_13_STABLE [98eb3e06c] 2022-03-23 18:22:10 +0100
Branch: REL_12_STABLE [c714ebd0e] 2022-03-23 18:22:10 +0100
Branch: REL_11_STABLE [199cd7b59] 2022-03-23 18:22:10 +0100
Branch: REL_10_STABLE [9ade3c09a] 2022-03-23 18:22:10 +0100
-->
<para>
Fix <quote>PANIC: xlog flush request is not satisfied</quote>
failure during standby promotion when there is a missing WAL
continuation record (Sami Imseih)
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [8f1537d10] 2022-05-02 18:25:00 -0700
Branch: REL_14_STABLE [9ab3b2bdb] 2022-05-02 18:25:59 -0700
Branch: REL_13_STABLE [57c5ad168] 2022-05-02 18:28:10 -0700
Branch: REL_12_STABLE [edfc03ec9] 2022-05-02 18:29:52 -0700
Branch: REL_11_STABLE [9cda785b4] 2022-05-02 18:30:15 -0700
Branch: REL_10_STABLE [cbc47ad7e] 2022-05-02 18:30:38 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: REL_14_STABLE [f74496dd6] 2022-05-02 18:26:09 -0700
Branch: REL_13_STABLE [0446d3bf3] 2022-05-02 18:29:35 -0700
Branch: REL_12_STABLE [a5ede1391] 2022-05-02 18:29:52 -0700
Branch: REL_11_STABLE [25d5494e2] 2022-05-02 18:30:15 -0700
Branch: REL_10_STABLE [b1f35a36e] 2022-05-02 18:30:38 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: REL_14_STABLE [5ab8e8014] 2022-05-02 18:09:42 -0700
Branch: REL_13_STABLE [90abe1e17] 2022-05-02 18:09:43 -0700
Branch: REL_12_STABLE [5c8b14a71] 2022-05-02 18:09:43 -0700
Branch: REL_11_STABLE [2adb8debe] 2022-05-02 18:09:44 -0700
Branch: REL_10_STABLE [e8a0cf9b2] 2022-05-02 18:09:44 -0700
-->
<para>
Fix possibility of self-deadlock in hot standby conflict handling
(Andres Freund)
</para>
<para>
With unlucky timing, the WAL-applying process could get stuck
while waiting for some other process to release a buffer lock.
</para>
</listitem>
<listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [c91f71b9d] 2022-03-16 18:05:58 +0100
Branch: REL_14_STABLE [677a1dc0c] 2022-03-16 18:06:27 +0100
Branch: REL_13_STABLE [27fafee72] 2022-03-16 18:14:33 +0100
-->
<para>
Fix possible mis-identification of the correct ancestor relation
to publish logical replication changes through (Tomas Vondra, Hou
zj, Amit Kapila)
</para>
<para>
If <varname>publish_via_partition_root</varname> is enabled, and
there are multiple publications naming different ancestors of the
currently-modified relation, the wrong ancestor might be chosen for
reporting the change.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [dd4ab6fd6] 2022-04-19 08:49:49 +0530
Branch: REL_14_STABLE [c9dea58e2] 2022-04-19 08:54:37 +0530
Branch: REL_13_STABLE [82d4a17a1] 2022-04-19 09:08:05 +0530
Branch: REL_12_STABLE [59348fbde] 2022-04-19 09:18:44 +0530
Branch: REL_11_STABLE [a90de822e] 2022-04-19 09:29:34 +0530
Branch: REL_10_STABLE [be46985be] 2022-04-19 09:38:25 +0530
-->
<para>
Ensure that logical replication apply workers can be restarted even
when we're up against
the <varname>max_sync_workers_per_subscription</varname> limit
(Amit Kapila)
</para>
<para>
Faulty coding of the limit check caused a restarted worker to exit
immediately, leaving fewer workers than there should be.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [5e01001ff] 2022-02-14 08:55:58 +0530
Branch: REL_14_STABLE [04645bbca] 2022-02-14 08:07:46 +0530
Branch: REL_13_STABLE [caa231be9] 2022-02-14 08:24:44 +0530
Branch: REL_12_STABLE [ce349cf17] 2022-02-14 08:27:56 +0530
Branch: REL_11_STABLE [1cd5802ac] 2022-02-14 08:37:23 +0530
Branch: REL_10_STABLE [b5e060473] 2022-02-14 08:45:54 +0530
-->
<para>
Include unchanged replica identity key columns in the WAL log for an
update, if they are stored out-of-line (Dilip Kumar, Amit Kapila)
</para>
<para>
Otherwise subscribers cannot see the values and will fail to
replicate the update.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0fb6954aa] 2022-03-27 12:57:46 -0400
Branch: REL_14_STABLE [3f7a59c59] 2022-03-27 12:57:52 -0400
Branch: REL_13_STABLE [9016a2a3d] 2022-03-27 12:57:57 -0400
-->
<para>
Cope correctly with platforms that have no support for altering the
server process's display in <application>ps(1)</application> (Andrew
Dunstan)
</para>
<para>
Few platforms are like this (the only supported one is Cygwin), so
we'd managed not to notice that refactoring introduced a potential
memory clobber.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [638300fef] 2022-02-25 17:40:43 -0500
Branch: REL_14_STABLE [ac910bb23] 2022-02-25 17:40:43 -0500
Branch: REL_13_STABLE [9b2d762a2] 2022-02-25 17:40:44 -0500
Branch: REL_12_STABLE [0f7b62f29] 2022-02-25 17:40:45 -0500
Branch: REL_11_STABLE [31befa6be] 2022-02-25 17:40:45 -0500
Branch: REL_10_STABLE [4936747c4] 2022-02-25 17:40:21 -0500
-->
<para>
Disallow execution of SPI functions during PL/Perl function
compilation (Tom Lane)
</para>
<para>
Perl can be convinced to execute user-defined code during compilation
of a PL/Perl function. However, it's not okay for such code to try
to invoke SQL operations via SPI. That results in a crash, and if
it didn't crash it would be a security hazard, because we really
don't want code execution during function validation. Put in a
check to give a friendlier error message instead.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a59c79564] 2022-02-28 14:12:52 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [50f03473e] 2022-03-02 11:29:11 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [2a1f84636] 2022-03-02 11:57:02 -0500
Branch: REL_13_STABLE [6599d8f12] 2022-03-02 11:57:02 -0500
Branch: REL_12_STABLE [72918ea86] 2022-03-02 11:57:02 -0500
Branch: REL_11_STABLE [5bb3d91ea] 2022-03-02 11:57:02 -0500
Branch: REL_10_STABLE [9050999ef] 2022-03-02 11:57:02 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [878e64d0f] 2022-03-31 11:24:26 -0400
Branch: REL_14_STABLE [402279afe] 2022-03-31 11:24:26 -0400
Branch: REL_13_STABLE [fb1d7f451] 2022-03-31 11:24:26 -0400
Branch: REL_12_STABLE [fcaf7d725] 2022-03-31 11:24:26 -0400
Branch: REL_11_STABLE [143043191] 2022-03-31 11:24:26 -0400
Branch: REL_10_STABLE [a6bd1f0ee] 2022-03-31 11:24:26 -0400
-->
<para>
Make <application>libpq</application> accept root-owned SSL private
key files (David Steele)
</para>
<para>
This change synchronizes <application>libpq</application>'s rules
for safe ownership and permissions of SSL key files with the rules
the server has used since release 9.6. Namely, in addition to the
current rules, allow the case where the key file is owned by root
and has permissions <literal>rw-r-----</literal> or less. This is
helpful for system-wide management of key files.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [335fa5a26] 2022-02-12 13:23:20 -0500
Branch: REL_14_STABLE [ae27b1acc] 2022-02-12 13:23:20 -0500
Branch: REL_13_STABLE [51ee561f5] 2022-02-12 13:23:20 -0500
Branch: REL_12_STABLE [c9d35dc7f] 2022-02-12 13:23:20 -0500
-->
<para>
Fix behavior of <application>libpq</application>'s
<function>PQisBusy()</function> function after a connection failure
(Tom Lane)
</para>
<para>
If we'd detected a write failure, <function>PQisBusy()</function>
would always return true, which is the wrong thing: we want input
processing to carry on normally until we've read whatever is
available from the server. The practical effect of this error is
that applications using <application>libpq</application>'s
async-query API would typically detect connection loss only
when <function>PQconsumeInput()</function> returns a hard failure.
With this fix, a connection loss will normally be reported via an
error <structname>PGresult</structname> object, which is a much
cleaner behavior for most applications.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a745b9365] 2022-02-10 16:49:39 -0500
Branch: REL_14_STABLE [1e8c5cf7c] 2022-02-10 16:49:39 -0500
Branch: REL_13_STABLE [d0e1fd958] 2022-02-10 16:49:39 -0500
Branch: REL_12_STABLE [61c20a5ea] 2022-02-10 16:49:39 -0500
Branch: REL_11_STABLE [69cc15c31] 2022-02-10 16:49:39 -0500
Branch: REL_10_STABLE [34523933b] 2022-02-10 16:49:39 -0500
-->
<para>
Make <application>pg_ctl</application> recheck postmaster aliveness
while waiting for stop/restart/promote actions (Tom Lane)
</para>
<para>
<application>pg_ctl</application> would verify that the postmaster
is alive as a side-effect of sending the stop or promote signal, but
then it just naively waited to see the on-disk state change. If the
postmaster died uncleanly without having removed its PID file or
updated the control file, <application>pg_ctl</application> would
wait until timeout. Instead make it recheck every so often that the
postmaster process is still there.
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [cd83cb953] 2022-02-25 10:30:05 -0800
Branch: REL_14_STABLE [9ff7fd906] 2022-02-25 10:31:16 -0800
Branch: REL_13_STABLE [0b1020a96] 2022-02-25 10:32:38 -0800
Branch: REL_12_STABLE [5407241a8] 2022-02-25 10:34:38 -0800
Branch: REL_11_STABLE [51c341656] 2022-02-25 10:40:32 -0800
Author: Andres Freund <andres@anarazel.de>
Branch: master [264d28492] 2022-03-27 18:13:50 -0700
Branch: REL_14_STABLE [6839aa7a6] 2022-03-27 18:15:10 -0700
Branch: REL_13_STABLE [344d89abf] 2022-03-27 18:15:14 -0700
Branch: REL_12_STABLE [5ebd262dc] 2022-03-27 18:15:15 -0700
Branch: REL_11_STABLE [7d935bdf7] 2022-03-27 18:15:17 -0700
-->
<para>
Fix error handling in <application>pg_waldump</application> (Kyotaro
Horiguchi, Andres Freund)
</para>
<para>
While trying to read a WAL file to determine the WAL segment size,
<application>pg_waldump</application> would report an incorrect
error for the case of a too-short file. In addition, the file name
reported in this and related error messages could be garbage.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [cd4868a57] 2022-04-14 15:08:03 +0900
Branch: REL_14_STABLE [df6bbe73b] 2022-04-14 15:09:26 +0900
Branch: REL_13_STABLE [2275d044d] 2022-04-14 15:09:36 +0900
Branch: REL_12_STABLE [5378d55cb] 2022-04-14 15:09:39 +0900
Branch: REL_11_STABLE [79fed072b] 2022-04-14 15:09:42 +0900
Branch: REL_10_STABLE [12d32b7bc] 2022-04-14 15:09:46 +0900
-->
<para>
Ensure that <filename>contrib/pageinspect</filename> functions cope
with all-zero pages (Michael Paquier)
</para>
<para>
This is a legitimate edge case, but the module was mostly unprepared
for it. Arrange to return nulls, or no rows, as appropriate; that
seems more useful than raising an error.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [291e517a4] 2022-03-27 17:53:40 +0900
Branch: REL_14_STABLE [27d384441] 2022-03-27 17:53:51 +0900
Branch: REL_13_STABLE [3d4d6dee0] 2022-03-27 17:53:55 +0900
Branch: REL_12_STABLE [5ca2aa2f2] 2022-03-27 17:53:59 +0900
Branch: REL_11_STABLE [1a2fdf86a] 2022-03-27 17:54:03 +0900
Branch: REL_10_STABLE [ab80b0fbb] 2022-03-27 17:54:08 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [076f4d953] 2022-03-16 11:19:39 +0900
Branch: REL_14_STABLE [b61e6214c] 2022-03-16 11:20:47 +0900
Branch: REL_13_STABLE [d3a9b83c3] 2022-03-16 11:20:51 +0900
Branch: REL_12_STABLE [af8a8eb54] 2022-03-16 11:20:54 +0900
Branch: REL_11_STABLE [2389ee8dd] 2022-03-16 11:20:57 +0900
Branch: REL_10_STABLE [c42b88932] 2022-03-16 11:21:00 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [4477dcb20] 2022-03-16 12:29:39 +0900
Branch: REL_14_STABLE [dc5b3bdae] 2022-03-16 12:29:47 +0900
Branch: REL_13_STABLE [028a3c6b1] 2022-03-16 12:29:55 +0900
Branch: REL_12_STABLE [5cb770210] 2022-03-16 12:29:59 +0900
Branch: REL_11_STABLE [09c97746d] 2022-03-16 12:30:02 +0900
Branch: REL_10_STABLE [07e343513] 2022-03-16 12:30:07 +0900
-->
<para>
In <filename>contrib/pageinspect</filename>, add defenses against
incorrect page <quote>special space</quote> contents, tighten checks
for correct page size, and add some missing checks that an index is
of the expected type (Michael Paquier, Justin Pryzby, Julien
Rouhaud)
</para>
<para>
These changes make it less likely that the module will crash on bad
data.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f3dd9fe1d] 2022-03-31 14:29:48 -0400
Branch: REL_14_STABLE [9f9489aa2] 2022-03-31 14:29:24 -0400
Branch: REL_13_STABLE [79df1d20c] 2022-03-31 14:29:24 -0400
Branch: REL_12_STABLE [989d3e4a2] 2022-03-31 14:29:24 -0400
Branch: REL_11_STABLE [b9eb0412f] 2022-03-31 14:29:24 -0400
Branch: REL_10_STABLE [728fc0f9a] 2022-03-31 14:29:24 -0400
-->
<para>
In <filename>contrib/postgres_fdw</filename>, verify
that <literal>ORDER BY</literal> clauses are safe to ship before
requesting a remotely-ordered query, and include
a <literal>USING</literal> clause if necessary (Ronan Dunklau)
</para>
<para>
This fix prevents situations where the remote server might sort in a
different order than we intend. While sometimes that would be only
cosmetic, it could produce thoroughly wrong results if the remote
data is used as input for a locally-performed merge join.
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [e6a760020] 2021-09-27 10:53:20 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [807fee1a3] 2022-02-04 16:16:10 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [a56e7b660] 2022-03-16 10:30:55 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: REL_14_STABLE [d9f7ad54e] 2022-03-16 11:42:00 +1300
Branch: REL_13_STABLE [5610411ac] 2022-03-16 11:41:13 +1300
Branch: REL_12_STABLE [45a469eb2] 2022-03-16 11:40:43 +1300
Branch: REL_11_STABLE [986d24042] 2022-03-16 11:35:00 +1300
-->
<para>
Update <acronym>JIT</acronym> code to work with LLVM 14
(Thomas Munro)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [46ab07ffd] 2022-03-03 18:13:24 -0500
Branch: REL_14_STABLE [b0bc196e5] 2022-03-03 18:13:24 -0500
Branch: REL_13_STABLE [1a027e6b7] 2022-03-03 18:13:24 -0500
Branch: REL_12_STABLE [f727b6ea8] 2022-03-03 18:13:24 -0500
Branch: REL_11_STABLE [f2087e26e] 2022-03-03 18:13:24 -0500
Branch: REL_10_STABLE [cfbe87bd6] 2022-03-03 18:13:24 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0fbdfaf79] 2022-03-03 19:03:17 -0500
Branch: REL_14_STABLE [5c9d17e94] 2022-03-03 19:03:35 -0500
Branch: REL_13_STABLE [97031f440] 2022-03-03 19:03:42 -0500
Branch: REL_12_STABLE [4b0696b36] 2022-03-03 19:03:46 -0500
Branch: REL_11_STABLE [566e1c04d] 2022-03-03 19:03:50 -0500
Branch: REL_10_STABLE [18c04d157] 2022-03-03 19:03:55 -0500
Author: Andres Freund <andres@anarazel.de>
Branch: master [3ac7d0241] 2022-03-23 13:05:59 -0700
Branch: REL_14_STABLE [81045e1e1] 2022-03-23 13:18:02 -0700
Branch: REL_13_STABLE [c0f99bb52] 2022-03-23 13:18:00 -0700
Branch: REL_12_STABLE [61a007fee] 2022-03-23 13:17:59 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: master [1c6bb380e] 2022-03-23 13:05:25 -0700
Branch: REL_14_STABLE [89a94c24a] 2022-03-23 13:13:18 -0700
Branch: REL_13_STABLE [8014c61eb] 2022-03-23 13:13:20 -0700
Branch: REL_12_STABLE [c5b60a68c] 2022-03-23 13:13:33 -0700
Branch: REL_11_STABLE [2121d5809] 2022-03-23 13:13:40 -0700
Branch: REL_10_STABLE [5f4615b9d] 2022-03-23 13:13:49 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: master [e71c76fca] 2022-03-23 12:43:14 -0700
Branch: REL_14_STABLE [e52e9bd57] 2022-03-23 12:43:41 -0700
Branch: REL_13_STABLE [7c163aa93] 2022-03-23 12:43:40 -0700
Branch: REL_12_STABLE [6a767bc2e] 2022-03-23 12:43:38 -0700
Branch: REL_11_STABLE [a77dddb42] 2022-03-23 12:43:36 -0700
Branch: REL_10_STABLE [2a9193726] 2022-03-23 12:43:33 -0700
-->
<para>
Clean up assorted failures under <productname>clang</productname>'s
<literal>-fsanitize=undefined</literal> checks (Tom Lane, Andres
Freund, Zhihong Yu)
</para>
<para>
Most of these changes are just for pro-forma compliance with the
letter of the C and POSIX standards, and are unlikely to have any
effect on production builds.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d5c2a91e5] 2022-02-08 19:25:56 -0500
Branch: REL_14_STABLE [e327291e4] 2022-02-08 19:26:09 -0500
Branch: REL_13_STABLE [5ea3b99de] 2022-02-08 19:26:17 -0500
Branch: REL_12_STABLE [eba0f095c] 2022-02-08 19:26:22 -0500
Branch: REL_11_STABLE [3a6e3a890] 2022-02-08 19:26:26 -0500
Branch: REL_10_STABLE [1a8b6f055] 2022-02-08 19:26:30 -0500
-->
<para>
Fix PL/Perl so it builds on C compilers that don't support statements
nested within expressions (Tom Lane)
</para>
<para>
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [097786fbb] 2022-03-22 08:22:02 -0700
Branch: REL_14_STABLE [2d608c960] 2022-03-22 08:28:51 -0700
Branch: REL_13_STABLE [f183e23cc] 2022-03-22 08:28:52 -0700
Branch: REL_12_STABLE [4553b960f] 2022-03-22 08:28:53 -0700
Branch: REL_11_STABLE [cd1951ba0] 2022-03-22 08:28:54 -0700
Branch: REL_10_STABLE [083031aa9] 2022-03-22 08:28:55 -0700
-->
<para>
Fix possible build failure of <application>pg_dumpall</application>
on Windows, when not using MSVC to build (Andres Freund)
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [ea09a75e1] 2022-02-10 13:44:05 -0500
Branch: REL_14_STABLE [92f60f536] 2022-02-10 13:51:19 -0500
Branch: REL_13_STABLE [eec7c640f] 2022-02-10 13:51:40 -0500
Branch: REL_12_STABLE [64dd64807] 2022-02-10 13:51:49 -0500
Branch: REL_11_STABLE [e2d104e19] 2022-02-10 13:51:59 -0500
Branch: REL_10_STABLE [a5eef80c2] 2022-02-10 13:52:05 -0500
Branch: REL9_6_STABLE [622ab6a34] 2022-02-10 13:52:37 -0500
Branch: REL9_5_STABLE [3a5034b5e] 2022-02-10 13:53:56 -0500
Branch: REL9_4_STABLE [c76164ea0] 2022-02-10 13:56:55 -0500
-->
<para>
In Windows builds, use <application>gendef</application> instead
of <application>pexports</application> to build DEF files (Andrew
Dunstan)
</para>
<para>
This adapts the build process to work on recent MSys tool chains.
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [b787c554c] 2022-04-25 15:47:55 -0400
Branch: REL_14_STABLE [71f394667] 2022-04-25 15:49:35 -0400
Branch: REL_13_STABLE [d9cede2c3] 2022-04-25 15:50:01 -0400
Branch: REL_12_STABLE [01f2bc5af] 2022-04-25 15:50:07 -0400
Branch: REL_11_STABLE [b90ce0dd7] 2022-04-25 15:51:27 -0400
Branch: REL_10_STABLE [58887d58c] 2022-04-25 15:51:58 -0400
-->
<para>
Prevent extra expansion of shell wildcard patterns in programs built
under MinGW (Andrew Dunstan)
</para>
<para>
For some reason the C library provided by MinGW will expand shell
wildcard characters in a program's command-line arguments by
default. This is confusing, not least because it doesn't happen
under MSVC, so turn it off.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ab3479bf5] 2022-05-05 14:54:53 -0400
Branch: REL_14_STABLE [77ee14ed9] 2022-05-05 14:55:03 -0400
Branch: REL_13_STABLE [e9735d1af] 2022-05-05 14:55:10 -0400
Branch: REL_12_STABLE [2bb9f7501] 2022-05-05 14:55:17 -0400
Branch: REL_11_STABLE [da72ff09b] 2022-05-05 14:55:22 -0400
Branch: REL_10_STABLE [bc334ec9f] 2022-05-05 14:55:30 -0400
-->
<para>
Update time zone data files to <application>tzdata</application>
release 2022a for DST law changes in Palestine, plus historical
corrections for Chile and Ukraine.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-13-6">
<title>Release 13.6</title>