Skip to content

P
Postgres FD Implementation
Commit 39387228 authored by Tom Lane's avatar Tom Lane
Browse files
Options

First-draft release notes for 14.1. 

As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.

Also as usual for a .1 release, there are some entries here that
are not really relevant for v14 because they already appeared in 14.0.
Those'll be removed later.
parent 02e20bb2
Show whitespace changes
Inline Side-by-side
Showing with 1950 additions and 0 deletions
doc/src/sgml/release-14.sgml
View file @ 39387228
<!-- doc/src/sgml/release-14.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-14-1">
<title>Release 14.1</title>
<formalpara>
<title>Release date:</title>
<para>2021-11-11</para>
</formalpara>
<para>
This release contains a variety of fixes from 14.0.
For information about new features in major release 14, see
<xref linkend="release-14"/>.
</para>
<sect2>
<title>Migration to Version 14.1</title>
<para>
A dump/restore is not required for those running 14.X.
</para>
<para>
However, note that installations using physical replication should
update standby servers before the primary server, as explained in
the first changelog entry below.
</para>
<para>
Also, several bugs have been found that may have resulted in corrupted
indexes, as explained in the next several changelog entries. If any
of those cases apply to you, it's recommended to reindex
possibly-affected indexes after updating.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [ff9f111bc] 2021-09-29 11:21:51 -0300
Branch: REL_14_STABLE [64a8687a6] 2021-09-29 11:41:01 -0300
Branch: REL_13_STABLE [1d97d3d08] 2021-09-29 11:21:51 -0300
Branch: REL_12_STABLE [1df0a914d] 2021-09-29 11:21:51 -0300
Branch: REL_11_STABLE [cfedb279a] 2021-09-29 11:21:51 -0300
Branch: REL_10_STABLE [d9fe2cc7d] 2021-09-29 11:21:51 -0300
Branch: REL9_6_STABLE [148c6ee3b] 2021-09-29 11:21:51 -0300
Branch: master [d03bca4d7] 2021-09-30 10:01:03 -0300
Branch: REL_14_STABLE [e3731bac5] 2021-09-30 10:01:03 -0300
Branch: master [d186d233d] 2021-10-01 18:03:11 -0300
Branch: REL_14_STABLE [0ce67bce0] 2021-10-01 18:03:11 -0300
Branch: master [010e52337] 2021-10-13 18:49:27 -0300
Branch: REL_14_STABLE [79c7fe1af] 2021-10-13 18:49:27 -0300
Branch: REL_13_STABLE [2cdf97fd1] 2021-10-13 18:49:27 -0300
Branch: REL_12_STABLE [4b7abbe48] 2021-10-13 18:49:27 -0300
Branch: REL_11_STABLE [6287b8e19] 2021-10-13 18:49:27 -0300
Branch: REL_10_STABLE [41cce2326] 2021-10-13 18:49:27 -0300
Branch: REL9_6_STABLE [5ec87619b] 2021-10-13 18:49:27 -0300
Branch: REL_14_STABLE [494ec0037] 2021-11-01 13:07:23 -0300
Branch: REL_13_STABLE [17227825c] 2021-11-01 13:07:23 -0300
Branch: REL_12_STABLE [da782bc93] 2021-11-01 13:07:23 -0300
Branch: REL_11_STABLE [5ef210047] 2021-11-01 13:07:23 -0300
Branch: REL_10_STABLE [656312c2a] 2021-11-01 13:07:23 -0300
Branch: REL9_6_STABLE [99197701e] 2021-11-01 13:07:23 -0300
-->
<para>
Fix physical replication for cases where the primary crashes
after shipping a WAL segment that ends with a partial WAL record
(&Aacute;lvaro Herrera)
</para>
<para>
If the primary did not survive long enough to finish writing the
rest of the incomplete WAL record, then the previous crash-recovery
logic had it back up and overwrite WAL starting from the beginning
of the incomplete WAL record. This is problematic since standby
servers may already have copies of that WAL segment. They will then
see an inconsistent next segment, and will not be able to recover
without manual intervention. To fix, do not back up over a WAL
segment boundary when restarting after a crash. Instead write a new
type of WAL record at the start of the next WAL segment, informing
readers that the incomplete WAL record will never be finished and
must be disregarded.
</para>
<para>
When applying this update, it's best to update standby servers
before the primary, so that they will be ready to handle this new
WAL record type if the primary happens to crash.
</para>
</listitem>
<listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [9bacec15b] 2021-11-02 12:06:17 -0700
Branch: REL_14_STABLE [61a86ed55] 2021-11-02 12:06:16 -0700
-->
<para>
Ensure that parallel <command>VACUUM</command> doesn't miss any
indexes (Peter Geoghegan, Masahiko Sawada)
</para>
<para>
A parallel <command>VACUUM</command> would fail to process indexes
that are below the <varname>min_parallel_index_scan_size</varname>
cutoff, if the table also has at least two indexes that are above
that size. This could result in those indexes becoming corrupt,
since they'd still contain references to any heap entries removed by
the <command>VACUUM</command>; subsequent queries using such indexes
would be likely to return rows they shouldn't.
This problem does not affect autovacuum, since it doesn't use
parallel vacuuming. However, it is advisable to reindex any
manually-vacuumed tables that have the right mix of index sizes.
</para>
</listitem>
<listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [3cd9c3b92] 2021-10-23 18:36:38 -0700
Branch: REL_14_STABLE [a5b9a0000] 2021-10-23 18:36:42 -0700
Branch: REL_13_STABLE [a9d0a5409] 2021-10-23 18:36:42 -0700
Branch: REL_12_STABLE [fe5d44a1d] 2021-10-23 18:36:42 -0700
Branch: REL_11_STABLE [df6158139] 2021-10-23 18:36:43 -0700
Branch: REL_10_STABLE [560124a37] 2021-10-23 18:36:43 -0700
Branch: REL9_6_STABLE [518493243] 2021-10-23 18:36:43 -0700
-->
<para>
Fix <command>CREATE INDEX CONCURRENTLY</command> to wait for
the latest prepared transactions (Andrey Borodin)
</para>
<para>
Rows inserted by just-prepared transactions might be omitted from
the new index, causing queries relying on the index to miss such
rows. The previous fix for this type of problem failed to account
for <command>PREPARE TRANSACTION</command> commands that were still
in progress when <command>CREATE INDEX CONCURRENTLY</command>
checked for them. As before, in installations that have enabled
prepared transactions (<varname>max_prepared_transactions</varname>
&gt; 0), it's recommended to reindex any concurrently-built indexes
in case this problem occurred when they were built.
</para>
</listitem>
<listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [fdd965d07] 2021-10-23 18:36:38 -0700
Branch: REL_14_STABLE [dde966efb] 2021-10-23 18:36:42 -0700
Branch: REL_13_STABLE [2e33b4359] 2021-10-23 18:36:42 -0700
Branch: REL_12_STABLE [0869e53d3] 2021-10-23 18:36:42 -0700
Branch: REL_11_STABLE [5141e471b] 2021-10-23 18:36:43 -0700
Branch: REL_10_STABLE [db86746fd] 2021-10-23 18:36:43 -0700
Branch: REL9_6_STABLE [e428699cb] 2021-10-23 18:36:43 -0700
-->
<para>
Avoid race condition that can cause backends to fail to add entries
for new rows to an index being built concurrently (Noah Misch,
Andrey Borodin)
</para>
<para>
While it's apparently rare in the field, this case could potentially
affect any index built or reindexed with
the <literal>CONCURRENTLY</literal> option. It is recommended to
reindex any such indexes to make sure they are correct.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ce773f230] 2021-09-02 17:24:41 -0400
Branch: REL_14_STABLE Release: REL_14_0 [23c6bc581] 2021-09-02 17:24:42 -0400
Branch: REL_13_STABLE [be2beadaf] 2021-09-02 17:24:42 -0400
Branch: REL_12_STABLE [a3bf13673] 2021-09-02 17:24:42 -0400
Branch: REL_11_STABLE [ad66373ea] 2021-09-02 17:24:42 -0400
Branch: REL_10_STABLE [2bb20e34c] 2021-09-02 17:24:42 -0400
Branch: REL9_6_STABLE [dea212e24] 2021-09-02 17:24:42 -0400
Branch: master [fd549145d] 2021-09-03 10:01:02 -0400
Branch: REL_14_STABLE Release: REL_14_0 [08b96a2b5] 2021-09-03 10:01:02 -0400
Branch: REL_13_STABLE [9089f1543] 2021-09-03 10:01:02 -0400
Branch: REL_12_STABLE [1fab33c0b] 2021-09-03 10:01:02 -0400
Branch: REL_11_STABLE [2836d57e4] 2021-09-03 10:01:02 -0400
Branch: master [b30cc0fd6] 2021-09-04 16:29:08 -0400
Branch: REL_14_STABLE Release: REL_14_0 [718978d9d] 2021-09-04 16:29:08 -0400
Branch: REL_13_STABLE [2c0dd669c] 2021-09-04 16:29:08 -0400
Branch: REL_12_STABLE [fd295d0c6] 2021-09-04 16:29:08 -0400
Branch: REL_11_STABLE [8782a8452] 2021-09-04 16:29:08 -0400
Branch: REL_10_STABLE [70354dd56] 2021-09-04 16:29:08 -0400
Branch: REL9_6_STABLE [a5e8f7b37] 2021-09-04 16:29:08 -0400
-->
<para>
Fix <type>float4</type> and <type>float8</type> hash functions to
produce uniform results for NaNs (Tom Lane)
</para>
<para>
Since <productname>PostgreSQL</productname>'s floating-point types
deem all NaNs to be equal, it's important for the hash functions to
produce the same hash code for all bit-patterns that are NaNs
according to the IEEE 754 standard. This failed to happen before,
meaning that hash indexes and hash-based query plans might produce
incorrect results for non-canonical NaN values.
(<literal>'-NaN'::float8</literal> is one way to produce such a
value on most machines.) It is advisable to reindex hash indexes
on floating-point columns, if there is any possibility that they
might contain such values.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [add5cf28d] 2021-11-01 11:38:23 +0900
Branch: REL_14_STABLE [f255de9a4] 2021-11-01 11:40:22 +0900
Branch: REL_13_STABLE [77f7909a4] 2021-11-01 11:40:29 +0900
-->
<para>
Fix <command>REINDEX CONCURRENTLY</command> to preserve operator
class parameters that were attached to the target index
(Michael Paquier)
</para>
</listitem>
<listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [97ddda8a8] 2021-08-27 23:33:23 -0700
Branch: REL_14_STABLE Release: REL_14_0 [5513c09c8] 2021-08-27 23:33:27 -0700
Branch: REL_13_STABLE [b18669f5e] 2021-08-27 23:33:27 -0700
Branch: REL_12_STABLE [a494f1023] 2021-08-27 23:34:03 -0700
Branch: REL_11_STABLE [6ebd2426b] 2021-08-27 23:34:22 -0700
Branch: REL_10_STABLE [f11c1bb17] 2021-08-27 23:42:53 -0700
Branch: REL9_6_STABLE [978998dbd] 2021-08-27 23:44:55 -0700
-->
<para>
Prevent data loss during crash recovery of <command>CREATE
TABLESPACE</command>, when <varname>wal_level</varname>
= <literal>minimal</literal> (Noah Misch)
</para>
<para>
If the server crashed between <command>CREATE TABLESPACE</command>
and the next checkpoint, replay would fully remove the contents of
the new tablespace's directory, relying on subsequent WAL replay
to restore everything within that directory. This interacts badly
with optimizations that skip writing WAL (one example
is <command>COPY</command> into a just-created table). Such
optimizations are applied only when <varname>wal_level</varname>
is <literal>minimal</literal>, which is not the default in v10 and
later.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [98ec35b0b] 2021-10-21 10:39:01 +0900
Branch: REL_14_STABLE [5040c9641] 2021-10-21 10:39:07 +0900
-->
<para>
Fix incorrect creation of shared dependencies when cloning a
database that contains non-builtin objects (Aleksander Alekseev)
</para>
<para>
The effects of this error are probably limited in practice. In
principle, it could allow a role to be dropped while it still owns
objects; but most installations would never want to drop a role
that had been used for objects they'd added
to <literal>template1</literal>.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [d6f1e16c8] 2021-10-18 19:08:25 -0300
Branch: REL_14_STABLE [72d064217] 2021-10-18 19:08:25 -0300
Branch: REL_13_STABLE [fe35528a5] 2021-10-18 19:08:25 -0300
Branch: REL_12_STABLE [8b26be8a3] 2021-10-18 19:08:25 -0300
Branch: REL_11_STABLE [b703b7d31] 2021-10-18 19:08:25 -0300
Branch: REL_10_STABLE [d36bdc4e9] 2021-10-18 19:08:25 -0300
-->
<para>
Ensure that the relation cache is invalidated for a table being
attached to or detached from a partitioned table (Amit Langote,
&Aacute;lvaro Herrera)
</para>
<para>
This oversight could allow misbehavior of subsequent inserts/updates
addressed directly to the partition, but only in currently-existing
sessions.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [4548c7673] 2021-09-22 08:00:54 +0530
Branch: REL_14_STABLE Release: REL_14_0 [9eff85932] 2021-09-22 08:13:37 +0530
Branch: REL_13_STABLE [f09a81f1c] 2021-09-22 08:24:20 +0530
-->
<para>
Ensure that the relation cache is invalidated for all partitions
of a partitioned table that is being added to or removed from a
publication (Hou Zhijie, Vignesh C)
</para>
<para>
This oversight could lead to improper replication behavior until all
currently-existing sessions have exited.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [8bd534274] 2021-09-08 11:50:37 +0530
Branch: REL_14_STABLE Release: REL_14_0 [8db27fbc1] 2021-09-08 12:08:29 +0530
Branch: REL_13_STABLE [ddfc7299d] 2021-09-08 12:14:59 +0530
Branch: REL_12_STABLE [2eb09f27d] 2021-09-08 12:16:15 +0530
Branch: REL_11_STABLE [96e38fa5e] 2021-09-08 11:20:42 +0530
Branch: REL_10_STABLE [28cde380c] 2021-09-08 11:23:01 +0530
-->
<para>
Ensure that the relation cache is invalidated when creating or
dropping a <literal>FOR ALL TABLES</literal> publication
(Hou Zhijie, Vignesh C)
</para>
<para>
This oversight could lead to improper replication behavior until all
currently-existing sessions have exited.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [5b0e7fe1d] 2021-10-13 16:38:07 +0900
Branch: REL_14_STABLE [922e15c47] 2021-10-13 16:38:15 +0900
-->
<para>
Fix corruption of parse tree while creating a range type (Alex
Kozhemyakin, Sergey Shinderuk)
</para>
<para>
<command>CREATE TYPE</command> incorrectly freed an element of the
parse tree, which could cause problems for a later event trigger, or
if the <command>CREATE TYPE</command> command was stored in the plan
cache and used again later.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5c056b0c2] 2021-08-06 17:32:54 -0400
Branch: REL_14_STABLE Release: REL_14_0 [e5f6493e3] 2021-08-06 17:32:54 -0400
Branch: REL_13_STABLE [dede14399] 2021-09-20 11:48:52 -0400
Branch: REL_12_STABLE [f230614da] 2021-09-20 11:48:52 -0400
Branch: REL_11_STABLE [914e54501] 2021-09-20 11:48:52 -0400
Branch: REL_10_STABLE [923b7efc2] 2021-09-20 11:48:52 -0400
Branch: REL9_6_STABLE [183b3aced] 2021-09-20 11:48:52 -0400
-->
<para>
Don't discard a cast to the same type with unspecified type modifier
(Tom Lane)
</para>
<para>
For example, if column <literal>f1</literal> is of
type <literal>numeric(18,3)</literal>, the parser used to simply
discard a cast like <literal>f1::numeric</literal>, on the grounds
that it would have no run-time effect. That's true, but the exposed
type of the expression should still be considered to be
plain <literal>numeric</literal>,
not <literal>numeric(18,3)</literal>. This is important for
correctly resolving the type of larger constructs, such
as recursive <literal>UNION</literal>s.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3e310d837] 2021-10-19 13:54:45 -0400
Branch: REL_14_STABLE [04dae19f4] 2021-10-19 13:54:45 -0400
Branch: REL_13_STABLE [30e61a8cd] 2021-10-19 13:54:46 -0400
Branch: REL_12_STABLE [ae7b1dd59] 2021-10-19 13:54:46 -0400
Branch: REL_11_STABLE [0d08c279b] 2021-10-19 13:54:46 -0400
-->
<para>
Fix updates of element fields in arrays of domain over composite
(Tom Lane)
</para>
<para>
A command such as <literal>UPDATE tab SET fld[1].subfld =
value</literal> failed if the array elements were domains rather
than plain composites.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [c6bc655ee] 2021-10-01 18:29:18 -0300
Branch: REL_14_STABLE [20047609d] 2021-10-01 18:29:18 -0300
Branch: REL_13_STABLE [170206e45] 2021-10-01 18:29:18 -0300
-->
<para>
Disallow the combination of <literal>FETCH FIRST WITH TIES</literal>
and <literal>FOR UPDATE SKIP LOCKED</literal> (David Christensen)
</para>
<para>
<literal>FETCH FIRST WITH TIES</literal> necessarily fetches
one more row than requested, so tha it can determine whether the
next row is a tie or not. In our current implementation,
if <literal>FOR UPDATE</literal> is used then that row will also get
locked even though it is not returned. That results in undesirable
behavior if the <literal>SKIP LOCKED</literal> option is specified.
It's difficult to change this without introducing a different set of
undesirable behaviors, so for now, forbid the combination.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [db2760a84] 2021-09-03 16:39:03 -0400
Branch: REL_14_STABLE Release: REL_14_0 [2cc018ba8] 2021-09-03 16:39:04 -0400
Branch: REL_13_STABLE [132be6000] 2021-09-03 16:38:55 -0400
Branch: REL_12_STABLE [9046a0536] 2021-09-03 16:38:55 -0400
Branch: REL_11_STABLE [9ebe2852e] 2021-09-03 16:38:55 -0400
Branch: REL_10_STABLE [5d7c6b6c8] 2021-09-03 16:38:55 -0400
-->
<para>
Disallow creating an ICU collation if the current database's
encoding won't support it (Tom Lane)
</para>
<para>
Previously this was allowed, but the collation effectively vanished
into the ether because of the way collation lookup works: you could
not use the collation, nor even drop it.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [fdd885714] 2021-10-19 11:03:52 +0900
Branch: REL_14_STABLE [b1b797ec7] 2021-10-19 11:04:00 +0900
Branch: REL_13_STABLE [85dc4292a] 2021-10-19 11:04:04 +0900
-->
<para>
Disallow <literal>ALTER INDEX index ALTER COLUMN col SET
(options)</literal> (Nathan Bossart, Michael Paquier)
</para>
<para>
While the parser accepts this, it's undocumented and doesn't
actually work.
</para>
</listitem>
<listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [e54a758d2] 2021-10-06 13:16:51 +0100
Branch: REL_14_STABLE [8e26b868d] 2021-10-06 13:19:25 +0100
Branch: REL_13_STABLE [9ab94ccb1] 2021-10-06 13:20:23 +0100
Branch: REL_12_STABLE [676218034] 2021-10-06 13:21:27 +0100
Branch: REL_11_STABLE [b2a0f1673] 2021-10-06 13:22:33 +0100
Branch: REL_10_STABLE [4853baaac] 2021-10-06 13:23:13 +0100
Branch: REL9_6_STABLE [0de8f9bc8] 2021-10-06 13:24:22 +0100
-->
<para>
Fix corner-case loss of precision in
numeric <function>power()</function> (Dean Rasheed)
</para>
<para>
The result could be inaccurate when the first argument is very close
to 1.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [65dc30ced] 2021-08-24 16:37:26 -0400
Branch: REL_14_STABLE Release: REL_14_0 [244dd7992] 2021-08-24 16:37:27 -0400
Branch: REL_13_STABLE [071146184] 2021-08-24 16:37:27 -0400
Branch: REL_12_STABLE [92620e82f] 2021-08-24 16:37:27 -0400
Branch: REL_11_STABLE [3ebd32e70] 2021-08-24 16:37:27 -0400
Branch: REL_10_STABLE [062c4c791] 2021-08-24 16:37:27 -0400
Branch: REL9_6_STABLE [7e75fe390] 2021-08-24 16:37:27 -0400
-->
<para>
Avoid regular expression errors with capturing parentheses
inside <literal>{0}</literal> (Tom Lane)
</para>
<para>
Regular expressions like <literal>(.){0}...\1</literal> drew
<quote>invalid backreference number</quote>. Other regexp engines
such as Perl don't complain, though, and for that matter ours
doesn't either in some closely related cases. Worse, it could throw
an assertion failure instead. Fix it so that no error is thrown and
instead the back-reference is silently deemed to never match.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9bbf6f734] 2021-08-23 17:41:07 -0400
Branch: REL_14_STABLE Release: REL_14_0 [779557bd2] 2021-08-23 17:41:07 -0400
Branch: REL_13_STABLE [9a327179c] 2021-08-23 17:41:07 -0400
Branch: REL_12_STABLE [b9521a1f9] 2021-08-23 17:41:07 -0400
Branch: REL_11_STABLE [08e080756] 2021-08-23 17:41:07 -0400
Branch: REL_10_STABLE [df87b7c44] 2021-08-23 17:41:07 -0400
Branch: REL9_6_STABLE [d90e14414] 2021-08-23 17:41:07 -0400
-->
<para>
Prevent regular expression back-references from sometimes matching
when they shouldn't (Tom Lane)
</para>
<para>
The regexp engine was careless about clearing match data
for capturing parentheses after rejecting a partial match. This
could allow a later back-reference to succeed when by rights it
should fail for lack of a defined referent.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [facce1da9] 2021-08-20 14:19:04 -0400
Branch: REL_14_STABLE Release: REL_14_0 [57a2d4a1b] 2021-08-20 14:19:04 -0400
Branch: REL_13_STABLE [b30f7f399] 2021-08-20 14:19:04 -0400
Branch: REL_12_STABLE [adbfde3db] 2021-08-20 14:19:04 -0400
Branch: REL_11_STABLE [9610852ab] 2021-08-20 14:19:04 -0400
Branch: REL_10_STABLE [e0f2acf26] 2021-08-20 14:19:04 -0400
Branch: REL9_6_STABLE [cafebd663] 2021-08-20 14:19:04 -0400
-->
<para>
Fix regular expression performance bug with back-references inside
iteration nodes (Tom Lane)
</para>
<para>
Unnecessarily stupid back-tracking logic could result in exponential
time spent looking for a match. Fortunately the problem is masked
in most cases by other optimizations; but it is possible to
demonstrate it with fairly simple, if contrived, regexps.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE Release: REL_14_0 [599c73a91] 2021-09-06 11:29:52 -0400
Branch: REL_13_STABLE [d8a266c5e] 2021-09-06 11:29:52 -0400
Branch: REL_12_STABLE [eb3c8d248] 2021-09-06 11:29:52 -0400
Branch: REL_11_STABLE [90b4647f6] 2021-09-06 11:29:52 -0400
Branch: REL_10_STABLE [b28c862a6] 2021-09-06 11:29:52 -0400
Branch: REL9_6_STABLE [5907c3818] 2021-09-06 11:29:52 -0400
-->
<para>
Fix incorrect results from <literal>AT TIME ZONE</literal> applied
to a <type>time with time zone</type> value (Tom Lane)
</para>
<para>
The results were incorrect if the target time zone was specified by
a dynamic timezone abbreviation (that is, one that is defined as
equivalent to a full time zone name, rather than a fixed UTC offset).
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9b8d68cc6] 2021-10-02 16:05:42 -0400
Branch: REL_14_STABLE [fa8db4879] 2021-10-02 16:06:09 -0400
Branch: REL_13_STABLE [9c76689de] 2021-10-02 16:06:23 -0400
Branch: REL_12_STABLE [e5b25f19b] 2021-10-02 16:06:45 -0400
Branch: REL_11_STABLE [9cc919b51] 2021-10-02 16:06:55 -0400
Branch: REL_10_STABLE [e323630cd] 2021-10-02 16:07:16 -0400
Branch: REL9_6_STABLE [dbec5a2fe] 2021-10-02 16:07:37 -0400
Branch: master [ad740067a] 2021-10-02 16:05:10 -0400
Branch: REL_14_STABLE [81464999b] 2021-10-02 16:06:09 -0400
Branch: REL_13_STABLE [7ba8eb81f] 2021-10-02 16:06:23 -0400
Branch: REL_12_STABLE [4721e8aa6] 2021-10-02 16:06:45 -0400
Branch: REL_11_STABLE [bb6d42669] 2021-10-02 16:06:55 -0400
Branch: REL_10_STABLE [cb0799db0] 2021-10-02 16:07:16 -0400
Branch: REL9_6_STABLE [37cbe0f79] 2021-10-02 16:07:36 -0400
Branch: master [c1aa3b3c0] 2021-10-04 14:52:39 -0400
Branch: REL_14_STABLE [919c08d90] 2021-10-04 14:52:17 -0400
Branch: REL_13_STABLE [c53ff69e1] 2021-10-04 14:52:17 -0400
Branch: REL_12_STABLE [07873a5dc] 2021-10-04 14:52:17 -0400
Branch: REL_11_STABLE [d0b0b70dc] 2021-10-04 14:52:17 -0400
Branch: REL_10_STABLE [cd2479142] 2021-10-04 14:52:17 -0400
Branch: REL9_6_STABLE [b5f34ae08] 2021-10-04 14:52:17 -0400
-->
<para>
Use the CLDR project's data to map Windows time zone names to IANA
time zones (Tom Lane)
</para>
<para>
When running on Windows, <application>initdb</application> attempts
to set the new cluster's <varname>timezone</varname> parameter to
the IANA time zone matching the system's prevailing time zone.
We were using a mapping table that we'd generated years ago and
updated only fitfully; unsurprisingly, it contained a number of
errors as well as omissions of recently-added zones. It turns out
that CLDR has been tracking the most appropriate mappings, so start
using their data. This change will not affect any existing
installation, only newly-initialized clusters.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4d5f651f1] 2021-10-14 12:43:55 -0400
Branch: REL_14_STABLE [fd059ac2e] 2021-10-14 12:43:43 -0400
Branch: REL_13_STABLE [fdd6a4d8d] 2021-10-14 12:43:43 -0400
-->
<para>
Fix planner error with pulling up subquery expressions into function
rangetable entries (Tom Lane)
</para>
<para>
If a function in <literal>FROM</literal> laterally references the
output of some sub-<literal>SELECT</literal> earlier in
the <literal>FROM</literal> clause, and we are able to flatten that
sub-<literal>SELECT</literal> into the outer query, the
expression(s) copied into the function expression were not fully
processed. This could lead to crashes at execution.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a21049fd3] 2021-09-17 15:41:16 -0400
Branch: REL_14_STABLE Release: REL_14_0 [4d5b4483d] 2021-09-17 15:41:16 -0400
Branch: REL_13_STABLE [e0b0d1eab] 2021-09-17 15:41:16 -0400
Branch: REL_12_STABLE [febe013ca] 2021-09-17 15:41:16 -0400
-->
<para>
Fix mistranslation of PlaceHolderVars to inheritance child relations
(Tom Lane)
</para>
<para>
This error could result in assertion failures, or in mis-planning of
queries having partitioned or inherited tables on the nullable side
of an outer join.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8c1144ba7] 2021-10-01 14:59:35 -0400
Branch: REL_14_STABLE [a54509bfd] 2021-10-01 14:59:35 -0400
Branch: REL_13_STABLE [7adbe186f] 2021-10-01 14:59:35 -0400
Branch: REL_12_STABLE [334fb8c3d] 2021-10-01 14:59:35 -0400
Branch: REL_11_STABLE [5863d348a] 2021-10-01 14:59:35 -0400
Branch: REL_10_STABLE [f951ea3a2] 2021-10-01 14:59:35 -0400
-->
<para>
Avoid using MCV-only statistics to estimate the range of a column
(Tom Lane)
</para>
<para>
There are corner cases in which <command>ANALYZE</command> will
build a most-common-values (MCV) list but not a histogram, even
though the MCV list does not account for all the observed values.
In such cases, keep the planner from using the MCV list alone to
estimate the range of column values.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7b5d4c29e] 2021-10-01 11:10:12 -0400
Branch: REL_14_STABLE [e6adaa179] 2021-10-01 11:10:12 -0400
Branch: REL_13_STABLE [04ef2021e] 2021-10-01 11:10:12 -0400
Branch: REL_12_STABLE [cded2c460] 2021-10-01 11:10:12 -0400
Branch: REL_11_STABLE [5abbda985] 2021-10-01 11:10:12 -0400
-->
<para>
Fix restoration of a Portal's snapshot inside a subtransaction
(Bertrand Drouvot)
</para>
<para>
If a procedure commits or rolls back a transaction, and then its
next significant action is inside a new subtransaction, snapshot
management went wrong, leading to a dangling pointer and probable
crash. A typical example in PL/pgSQL is a <literal>COMMIT</literal>
immediately followed by a <literal>BEGIN ... EXCEPTION</literal>
block that performs a query.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [409f9ca44] 2021-10-18 11:55:42 +0900
Branch: REL_14_STABLE [5b353aaff] 2021-10-18 11:56:48 +0900
Branch: REL_13_STABLE [8f4fe8d7f] 2021-10-18 11:56:52 +0900
Branch: REL_12_STABLE [a207b8521] 2021-10-18 11:56:54 +0900
Branch: REL_11_STABLE [506aa1f71] 2021-10-18 11:56:57 +0900
Branch: REL_10_STABLE [d1a6a08df] 2021-10-18 11:57:02 +0900
Branch: REL9_6_STABLE [f49bf8263] 2021-10-18 11:57:07 +0900
-->
<para>
Clean up correctly if a transaction fails after exporting its
snapshot (Dilip Kumar)
</para>
<para>
This oversight would only cause a problem if the same session
attempted to export a snapshot again. The most likely scenario for
that is creation of a replication slot (followed by rollback)
and then creation of another replication slot.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [8a4237908] 2021-10-04 14:05:20 +0900
Branch: REL_14_STABLE [828f7f000] 2021-10-04 14:05:48 +0900
Branch: REL_13_STABLE [194e535a0] 2021-10-04 14:05:52 +0900
Branch: REL_12_STABLE [3c3f118d5] 2021-10-04 14:05:55 +0900
Branch: REL_11_STABLE [0a561d4d0] 2021-10-04 14:05:59 +0900
Branch: REL_10_STABLE [8a6a1fe07] 2021-10-04 14:06:03 +0900
Branch: REL9_6_STABLE [e2b2a9e1c] 2021-10-04 14:06:09 +0900
-->
<para>
Ensure prepared transactions are properly accounted for during
promotion of a standby server (Michael Paquier, Andres Freund)
</para>
<para>
There was a narrow window where a prepared transaction could be
omitted from a snapshot taken by a concurrently-running session.
If that session then used the snapshot to perform data updates,
erroneous results or data corruption could occur.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1316be286] 2021-09-15 12:31:56 -0400
Branch: REL_14_STABLE Release: REL_14_0 [d84d62b62] 2021-09-15 12:31:56 -0400
Branch: REL_13_STABLE [e06cc024b] 2021-09-15 12:31:56 -0400
-->
<para>
Disallow <literal>LISTEN</literal> in background workers (Tom Lane)
</para>
<para>
There's no infrastructure to support this, so if someone did
it, it would only result in preventing cleanup of
the <literal>NOTIFY</literal> queue.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2e4eae87d] 2021-09-14 17:18:25 -0400
Branch: REL_14_STABLE Release: REL_14_0 [0eff10a00] 2021-09-14 17:18:25 -0400
Branch: REL_13_STABLE [63f28776c] 2021-09-14 17:18:25 -0400
-->
<para>
Send <literal>NOTIFY</literal> signals to other backends during
transaction commit, not in the server's idle loop (Artur Zakirov,
Tom Lane)
</para>
<para>
This change allows notifications to be delivered immediately after
an intra-procedure <literal>COMMIT</literal>. It also allows
logical replication workers to send notifications.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [39ae0ef85] 2021-10-11 11:56:52 -0400
Branch: REL_14_STABLE [2c25db32e] 2021-10-11 11:56:52 -0400
-->
<para>
Fix <quote>could not find RecursiveUnion</quote> error
when <command>EXPLAIN</command> tries to print a filter condition
attached to a WorkTableScan node (Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c1b7a6c27] 2021-09-10 13:18:32 -0400
Branch: REL_14_STABLE Release: REL_14_0 [d844cd75a] 2021-09-10 13:18:32 -0400
Branch: REL_13_STABLE [fa5d0415f] 2021-09-10 13:18:32 -0400
Branch: REL_12_STABLE [ba408fc96] 2021-09-10 13:18:32 -0400
Branch: REL_11_STABLE [9ea8d3d24] 2021-09-10 13:18:32 -0400
-->
<para>
Refuse to rewind a cursor marked <literal>NO SCROLL</literal>
if it has been held over from a previous transaction due
to the <literal>WITH HOLD</literal> option (Tom Lane)
</para>
<para>
We have long forbidden fetching backwards from a <literal>NO
SCROLL</literal> cursor, but for historical reasons the prohibition
didn't extend to cases in which we rewind the query altogether and
then re-fetch forwards. That exception leads to inconsistencies,
particularly for held-over cursors which may not have stored all the
data necessary to rewind. Disallow rewinding for non-scrollable
held-over cursors to block the worst inconsistencies. (v15 will
remove the exception altogether.)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [cba79a163] 2021-09-09 13:36:44 -0400
Branch: REL_14_STABLE Release: REL_14_0 [b7056c0a2] 2021-09-09 13:36:44 -0400
Branch: REL_13_STABLE [d8d93bc8b] 2021-09-09 13:36:31 -0400
Branch: REL_12_STABLE [2e75e969c] 2021-09-09 13:36:31 -0400
Branch: REL_11_STABLE [7813451c2] 2021-09-09 13:36:31 -0400
-->
<para>
Fix possible failure while saving a <literal>WITH HOLD</literal>
cursor at transaction end, if it had already been read to completion
(Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8481f9989] 2021-09-09 11:45:48 -0400
Branch: REL_14_STABLE Release: REL_14_0 [7430c7742] 2021-09-09 11:45:48 -0400
Branch: REL_13_STABLE [04118de78] 2021-09-09 11:45:48 -0400
Branch: REL_12_STABLE [a7a73ce30] 2021-09-09 11:45:48 -0400
Branch: REL_11_STABLE [1a23b669d] 2021-09-09 11:45:48 -0400
Branch: REL_10_STABLE [ca1dd6234] 2021-09-09 11:45:48 -0400
Branch: REL9_6_STABLE [cc4de2bba] 2021-09-09 11:45:48 -0400
-->
<para>
Fix detection of a relation that has grown to the maximum allowed
length (Tom Lane)
</para>
<para>
An attempt to extend a table or index past the limit of 2^32-1
blocks was rejected, but not soon enough to prevent inconsistent
internal state from being created.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [362e2dcc4] 2021-09-08 12:05:47 -0400
Branch: REL_14_STABLE Release: REL_14_0 [03d01d746] 2021-09-08 12:05:43 -0400
Branch: REL_13_STABLE [cbba6ba3a] 2021-09-08 12:05:43 -0400
Branch: REL_12_STABLE [1fedbcc7a] 2021-09-08 12:05:43 -0400
Branch: REL_11_STABLE [882b7e728] 2021-09-08 12:05:43 -0400
Branch: REL_10_STABLE [9de082399] 2021-09-08 12:05:43 -0400
Branch: REL9_6_STABLE [595ab8a54] 2021-09-08 12:05:43 -0400
-->
<para>
Correctly track the presence of data-modifying CTEs when expanding
a <literal>DO INSTEAD</literal> rule (Greg Nancarrow, Tom Lane)
</para>
<para>
The previous failure to do this could lead to problems such as
unsafely choosing a parallel plan.
</para>
</listitem>
<listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [5be8ce82e] 2021-08-31 18:33:38 +0200
Branch: REL_14_STABLE Release: REL_14_0 [a371a5ba3] 2021-08-31 18:36:06 +0200
Branch: REL_13_STABLE [1fe1a04af] 2021-08-31 18:38:11 +0200
Branch: REL_12_STABLE [6c8b98669] 2021-08-31 18:40:09 +0200
Branch: REL_11_STABLE [b46ff4b50] 2021-08-31 18:42:11 +0200
Branch: REL_10_STABLE [bfb732c0e] 2021-08-31 18:44:36 +0200
Branch: master [628bc9d13] 2021-08-31 19:31:10 +0200
Branch: REL_14_STABLE Release: REL_14_0 [4090ff2a9] 2021-08-31 19:32:32 +0200
Branch: REL_13_STABLE [c8213aa94] 2021-08-31 19:36:03 +0200
Branch: REL_12_STABLE [5f8dd5dc1] 2021-08-31 19:41:58 +0200
Branch: REL_11_STABLE [bce24d1ed] 2021-08-31 19:42:14 +0200
Branch: REL_10_STABLE [6963e723f] 2021-08-31 19:44:30 +0200
-->
<para>
Fix incorrect reporting of permissions failures on extended
statistics objects (Tomas Vondra)
</para>
<para>
The code typically produced <quote>cache lookup error</quote> rather
than the intended message.
</para>
</listitem>
<listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master [a780b2fcc] 2021-08-25 08:32:04 -0400
Branch: REL_14_STABLE Release: REL_14_0 [11c123988] 2021-08-25 08:33:53 -0400
Branch: REL_13_STABLE [bc062cb93] 2021-08-25 08:40:52 -0400
Branch: REL_12_STABLE [f4b77e82e] 2021-08-25 08:45:00 -0400
Branch: REL_11_STABLE [198cf81e2] 2021-08-25 08:48:01 -0400
Branch: REL_10_STABLE [96f6ef9fe] 2021-08-25 08:55:52 -0400
-->
<para>
Fix incorrect snapshot handling in parallel workers (Greg Nancarrow)
</para>
<para>
This oversight could lead to misbehavior in parallel queries if the
transaction isolation level is less than REPEATABLE READ.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [29b590547] 2021-08-25 09:53:07 +0530
Branch: REL_14_STABLE Release: REL_14_0 [9d7a80ce0] 2021-08-25 10:10:50 +0530
Branch: REL_13_STABLE [794025eff] 2021-08-25 09:23:27 +0530
Branch: REL_12_STABLE [e35705f54] 2021-08-25 09:32:56 +0530
Branch: REL_11_STABLE [bfdbda24b] 2021-08-25 09:43:33 +0530
-->
<para>
Fix logical decoding to correctly ignore toast-table changes for
transient tables (Bertrand Drouvot)
</para>
<para>
Logical decoding normally ignores changes in transient tables such
as those created during an <command>ALTER TABLE</command> heap
rewrite. But that filtering wasn't applied to the associated toast
table if any, leading to possible errors when rewriting a table
that's being published.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [df3640e52] 2021-09-13 10:24:00 +0530
Branch: REL_14_STABLE Release: REL_14_0 [f5e0ff463] 2021-09-13 10:35:00 +0530
Branch: REL_13_STABLE [58cf794ca] 2021-09-13 10:46:58 +0530
-->
<para>
Fix logical decoding's memory usage accounting to handle TOAST data
correctly (Bertrand Drouvot)
</para>
</listitem>
<listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [596ba75cb] 2021-09-09 23:56:57 +0900
Branch: REL_14_STABLE Release: REL_14_0 [b5ec22bf5] 2021-09-09 23:58:05 +0900
Branch: REL_13_STABLE [dd9b3fced] 2021-09-09 23:58:26 +0900
Branch: REL_12_STABLE [466535254] 2021-09-09 23:58:54 +0900
Branch: REL_11_STABLE [aacb3cfaf] 2021-09-09 23:59:19 +0900
Branch: REL_10_STABLE [f77489046] 2021-09-09 23:59:40 +0900
Branch: REL9_6_STABLE [61e2aa2db] 2021-09-10 00:00:06 +0900
-->
<para>
Fix walreceiver to ensure that it creates an archive notification
file before exiting (Fujii Masao)
</para>
<para>
This failed to happen if the walreceiver exited exactly at a WAL
segment boundary, thus delaying archiving of the new segment on the
standby.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [a3fcbcda7] 2021-08-23 11:09:33 +0900
Branch: REL_14_STABLE Release: REL_14_0 [65b649fec] 2021-08-23 11:09:54 +0900
Branch: REL_13_STABLE [29f942325] 2021-08-23 11:09:57 +0900
Branch: master [ec2133a44] 2021-10-06 13:28:23 +0900
Branch: REL_14_STABLE [ae254356f] 2021-10-06 13:28:30 +0900
Branch: REL_13_STABLE [d6d68e223] 2021-10-06 13:28:35 +0900
-->
<para>
Compute the correct WAL range to include in a backup manifest when a
timeline change is involved (Kyotaro Horiguchi)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8d2d6ec77] 2021-08-19 12:12:35 -0400
Branch: REL_14_STABLE Release: REL_14_0 [464900393] 2021-08-19 12:12:35 -0400
Branch: REL_13_STABLE [7fa367d96] 2021-08-19 12:12:35 -0400
Branch: REL_12_STABLE [0c13ee198] 2021-08-19 12:12:35 -0400
Branch: REL_11_STABLE [fbc1eed8a] 2021-08-19 12:12:35 -0400
Branch: REL_10_STABLE [2739a2810] 2021-08-19 12:12:36 -0400
Branch: REL9_6_STABLE [cc7fae5c2] 2021-08-19 12:12:36 -0400
-->
<para>
Avoid trying to lock the <literal>OLD</literal>
and <literal>NEW</literal> pseudo-relations in a rule
that uses <literal>SELECT FOR UPDATE</literal>
(Masahiko Sawada, Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2313dda9d] 2021-08-18 18:12:51 -0400
Branch: REL_14_STABLE Release: REL_14_0 [61f9dae2c] 2021-08-18 18:12:51 -0400
Branch: REL_13_STABLE [ecd4dd9f1] 2021-08-18 18:12:51 -0400
Branch: REL_12_STABLE [eb2f59b34] 2021-08-18 18:12:51 -0400
Branch: REL_11_STABLE [a65319f09] 2021-08-18 18:12:51 -0400
Branch: REL_10_STABLE [82ad7ecb4] 2021-08-18 18:12:51 -0400
Branch: REL9_6_STABLE [c09f56fed] 2021-08-18 18:12:51 -0400
-->
<para>
Fix parser's processing of aggregate <literal>FILTER</literal>
clauses (Tom Lane)
</para>
<para>
If the <literal>FILTER</literal> expression is a plain boolean column,
the semantic level of the aggregate could be mis-determined, leading
to not-per-spec behavior. If the <literal>FILTER</literal>
expression is itself a boolean-returning aggregate, an error should
be thrown but was not, likely resulting in a crash at execution.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [c2c618ff1] 2021-10-19 19:08:45 -0300
Branch: REL_14_STABLE [3ce3fb2f7] 2021-10-19 19:08:45 -0300
Branch: REL_13_STABLE [842fe6123] 2021-10-19 19:08:45 -0300
Branch: REL_12_STABLE [6c8d1c197] 2021-10-19 19:08:45 -0300
Branch: master [cd124d205] 2021-10-20 13:05:42 -0300
Branch: REL_14_STABLE [718278855] 2021-10-20 13:05:42 -0300
Branch: REL_13_STABLE [a73a3671d] 2021-10-20 13:05:42 -0300
Branch: REL_12_STABLE [3c8c49945] 2021-10-20 13:05:42 -0300
-->
<para>
Ensure correct lock level is used when renaming a table (Nathan
Bossart, &Aacute;lvaro Herrera)
</para>
<para>
For historical reasons, <command>ALTER INDEX ... RENAME</command>
can be applied to any sort of relation. The lock level required to
rename an index is lower than that required to rename a table or
other kind of relation, but the code got this wrong and would use
the weaker lock level whenever the command is spelled <command>ALTER
INDEX</command>.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [6b71c925c] 2021-08-17 14:29:22 -0400
Branch: REL_14_STABLE Release: REL_14_0 [8f51ee63d] 2021-08-17 14:29:22 -0400
Branch: REL_13_STABLE [7b01246e1] 2021-08-17 14:29:22 -0400
-->
<para>
Prevent <literal>ALTER TYPE/DOMAIN/OPERATOR ... SET</literal>
from changing extension membership (Tom Lane)
</para>
<para>
<literal>ALTER ... SET</literal> executed by an extension script
would cause the target object to become a member of the extension if
it was not already. In itself this isn't too troubling, since
there's little reason for an extension script to touch an object not
belonging to the extension. But <literal>ALTER TYPE SET</literal>
will recurse to dependent domains, thus causing them to also become
extension members. This causes unwanted side-effects from
extension upgrade scripts that use that command to adjust the
properties of a base type belonging to the extension. Fix by
redefining these <literal>ALTER</literal> cases to never change
extension membership.
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [edb4d95dd] 2021-09-13 18:26:15 -0700
Branch: REL_14_STABLE Release: REL_14_0 [4e86887e0] 2021-09-13 18:15:28 -0700
Branch: REL_13_STABLE [c49e6f9d9] 2021-09-13 18:26:18 -0700
Branch: REL_12_STABLE [43849b65f] 2021-09-13 18:26:18 -0700
Branch: REL_11_STABLE [dccffd9a2] 2021-09-13 18:26:18 -0700
-->
<para>
Avoid trying to clean up LLVM state after an error within LLVM
(Andres Freund, Justin Pryzby)
</para>
<para>
This prevents a likely crash during backend exit after a fatal LLVM
error.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [d74b54b3d] 2021-11-05 12:29:35 -0300
Branch: REL_14_STABLE [02e20bb2d] 2021-11-05 12:29:35 -0300
Branch: REL_13_STABLE [bf5cdcfd5] 2021-11-05 12:29:34 -0300
Branch: REL_12_STABLE [3eff168a2] 2021-11-05 12:29:34 -0300
Branch: REL_11_STABLE [92224e470] 2021-11-05 12:29:34 -0300
Branch: REL_10_STABLE [58b600f64] 2021-11-05 12:29:34 -0300
Branch: REL9_6_STABLE [e0eaeafd6] 2021-11-05 12:29:35 -0300
-->
<para>
Avoid null-pointer-dereference crash when dropping a role that owns
objects being dropped concurrently (&Aacute;lvaro Herrera)
</para>
</listitem>
<listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [6b1b405eb] 2021-11-03 10:52:38 +0200
Branch: REL_14_STABLE [4ebd740cd] 2021-11-03 10:54:33 +0200
Branch: REL_13_STABLE [07070c008] 2021-11-03 10:54:36 +0200
Branch: REL_12_STABLE [11a399f9c] 2021-11-03 10:54:39 +0200
Branch: REL_11_STABLE [6bf00da11] 2021-11-03 10:54:42 +0200
Branch: REL_10_STABLE [7b55bb892] 2021-11-03 11:09:08 +0200
Branch: REL9_6_STABLE [8f32afee0] 2021-11-03 11:15:02 +0200
Branch: master [d5ab0681b] 2021-11-03 19:38:17 +0200
Branch: REL_14_STABLE [f4e3b6271] 2021-11-03 19:41:35 +0200
Branch: REL_13_STABLE [b7299b664] 2021-11-03 19:41:38 +0200
Branch: REL_12_STABLE [7dc9a310e] 2021-11-03 19:41:41 +0200
Branch: REL_11_STABLE [b110af5f7] 2021-11-03 19:41:44 +0200
Branch: REL_10_STABLE [245799d39] 2021-11-03 19:41:46 +0200
Branch: REL9_6_STABLE [71aeaf245] 2021-11-03 19:41:49 +0200
-->
<para>
Prevent <quote>snapshot reference leak</quote> warning
when <function>lo_export()</function> or a related function fails
(Heikki Linnakangas)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3778bcb39] 2021-08-27 19:53:05 -0400
Branch: REL_14_STABLE Release: REL_14_0 [e84d4810c] 2021-08-27 19:53:06 -0400
Branch: REL_13_STABLE [dbb239d51] 2021-08-27 19:42:42 -0400
Branch: REL_12_STABLE [187b5fea9] 2021-08-27 19:42:42 -0400
Branch: REL_11_STABLE [7c1b0f4c3] 2021-08-27 19:42:42 -0400
Branch: REL_10_STABLE [6a787c83c] 2021-08-27 19:42:42 -0400
Branch: REL9_6_STABLE [9e959f7ed] 2021-08-27 19:42:42 -0400
-->
<para>
Ensure that scans of SP-GiST indexes are counted in the statistics
views (Tom Lane)
</para>
<para>
Incrementing the number-of-index-scans counter was overlooked in the
SP-GiST code, although per-tuple counters were advanced correctly.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [01fc65270] 2021-11-02 13:36:47 -0400
Branch: REL_14_STABLE [16a56774f] 2021-11-02 13:36:53 -0400
Branch: REL_13_STABLE [ada667b45] 2021-11-02 13:36:57 -0400
-->
<para>
Fix inefficient code generation for CoerceToDomain expression nodes
(Ranier Vilela)
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [e4ba1005c] 2021-08-16 12:10:22 +0900
Branch: REL_14_STABLE Release: REL_14_0 [f83d80ea1] 2021-08-16 12:11:49 +0900
Branch: REL_13_STABLE [7f0873f32] 2021-08-16 12:11:53 +0900
Branch: REL_12_STABLE [84c1bac57] 2021-08-16 12:11:56 +0900
Branch: REL_11_STABLE [d392e86fa] 2021-08-16 12:11:59 +0900
Branch: REL_10_STABLE [024fd44e0] 2021-08-16 12:12:02 +0900
Branch: REL9_6_STABLE [942416f4b] 2021-08-16 12:12:09 +0900
-->
<para>
Recalculate relevant wait intervals
if <varname>recovery_min_apply_delay</varname> is changed during
recovery (Soumyadeep Chakraborty, Ashwin Agrawal)
</para>
</listitem>
<listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [37450f2ca] 2021-08-13 16:41:26 +1200
Branch: REL_14_STABLE Release: REL_14_0 [dc23c77d0] 2021-08-13 16:41:56 +1200
Branch: REL_13_STABLE [4873da79d] 2021-08-13 16:42:35 +1200
Branch: REL_12_STABLE [75d8fe818] 2021-08-13 16:43:13 +1200
Branch: REL_11_STABLE [5a6b0f21e] 2021-08-13 16:43:46 +1200
Branch: REL_10_STABLE [4874886b4] 2021-08-13 16:44:18 +1200
-->
<para>
Fix infinite loop if a <filename>simplehash.h</filename> hash table
reaches 2^32 elements (Yura Sokolov)
</para>
<para>
It seems unlikely that this bug has yet been hit in practice, as it
would require <varname>work_mem</varname> settings of hundreds of
gigabytes for existing uses of <filename>simplehash.h</filename>.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [6301c3ada] 2021-10-31 15:31:29 -0400
Branch: REL_14_STABLE [8424dfced] 2021-10-31 15:31:38 -0400
Branch: REL_13_STABLE [df238aed1] 2021-10-31 15:31:44 -0400
Branch: master [e9d9ba2a4] 2021-11-01 16:24:39 -0400
Branch: REL_14_STABLE [ad87bf355] 2021-11-01 16:24:40 -0400
Branch: REL_13_STABLE [e477642a1] 2021-11-01 16:24:40 -0400
Branch: master [65c6cab13] 2021-11-02 11:31:54 -0400
Branch: REL_14_STABLE [08cfa5981] 2021-11-02 11:31:54 -0400
Branch: REL_13_STABLE [0151af40c] 2021-11-02 11:31:54 -0400
-->
<para>
Avoid O(N^2) behavior in some list-manipulation operations
(Nathan Bossart, Tom Lane)
</para>
<para>
These changes fix slow processing in several scenarios, including:
when a standby replays a transaction that held many exclusive locks
on the primary; when many files are due to be unlinked after a
checkpoint; when hash aggregation involves many batches; and when
<filename>pg_trgm</filename> extracts indexable conditions from a
complex regular expression. Only the first of these scenarios has
actually been reported from the field, but they all seem like
plausible consequences of inefficient list deletions.
</para>
</listitem>
<listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [83772cc78] 2021-09-23 18:05:10 +0200
Branch: REL_14_STABLE Release: REL_14_0 [bb7628e55] 2021-09-23 18:22:29 +0200
Branch: REL_13_STABLE [b564eb018] 2021-09-23 18:33:59 +0200
Branch: REL_12_STABLE [16d394c05] 2021-09-23 18:41:55 +0200
Branch: REL_11_STABLE [ac7290a20] 2021-09-23 18:48:03 +0200
Branch: REL_10_STABLE [3aac99068] 2021-09-23 18:54:30 +0200
Branch: master [ad8a166ca] 2021-09-23 18:13:36 +0200
Branch: REL_14_STABLE Release: REL_14_0 [abb2f9144] 2021-09-23 18:25:37 +0200
Branch: REL_13_STABLE [c0386f403] 2021-09-23 18:34:01 +0200
Branch: REL_12_STABLE [4185632e9] 2021-09-23 18:43:05 +0200
Branch: REL_11_STABLE [4487a7def] 2021-09-23 18:48:58 +0200
Branch: REL_10_STABLE [d77e085af] 2021-09-23 18:55:22 +0200
-->
<para>
Reduce memory consumption during calculation of extended statistics
(Justin Pryzby, Tomas Vondra)
</para>
</listitem>
<listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [a5213adf3] 2021-10-27 12:10:47 -0700
Branch: REL_14_STABLE [d078fe83d] 2021-10-27 12:10:45 -0700
Branch: REL_13_STABLE [f8cce4a3d] 2021-10-27 12:10:43 -0700
Branch: master [c2381b510] 2021-10-27 13:09:24 -0700
Branch: REL_14_STABLE [6cac34339] 2021-10-27 13:09:01 -0700
Branch: REL_13_STABLE [d5a2ffbce] 2021-10-27 13:09:00 -0700
-->
<para>
Add more defensive checks around B-tree posting list splits
(Peter Geoghegan)
</para>
<para>
This change should help detect index corruption involving duplicate
table TIDs.
</para>
</listitem>
<listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [e3e29cec1] 2021-10-12 09:50:17 +0900
Branch: REL_14_STABLE [62e821ad2] 2021-10-12 09:51:17 +0900
-->
<para>
Allow the autovacuum launcher process to respond
to <function>pg_log_backend_memory_contexts()</function> requests
more quickly (Koyu Tanigawa)
</para>
</listitem>
<listitem>
<!--
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [0ded7039f] 2021-10-01 22:47:05 +0200
Branch: REL_14_STABLE [a5e83ad79] 2021-10-01 22:47:05 +0200
-->
<para>
Fix memory leak in HMAC hash calculations (Sergey Shinderuk)
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [8781b0ce2] 2021-10-26 12:54:55 +1300
Branch: REL_14_STABLE [181361a0c] 2021-10-26 13:09:00 +1300
Branch: REL_13_STABLE [24b7cf8a5] 2021-10-26 13:04:40 +1300
Branch: REL_12_STABLE [8fef901e3] 2021-10-26 13:01:52 +1300
-->
<para>
Disallow setting <varname>huge_pages</varname>
to <literal>on</literal> when <varname>shared_memory_type</varname>
is <literal>sysv</literal> (Thomas Munro)
</para>
<para>
Previously, this setting was accepted, but it did nothing for lack
of any implementation.
</para>
</listitem>
<listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [8670b9b99] 2021-09-06 11:27:59 -0700
Branch: REL_14_STABLE Release: REL_14_0 [47d54b6ba] 2021-09-06 11:28:02 -0700
Branch: REL_13_STABLE [aae398a87] 2021-09-06 11:28:02 -0700
-->
<para>
Fix missing <application>libpq</application> functions on AIX
(Tony Reix)
</para>
<para>
Code reorganization led to the following documented functions not
being exported from <application>libpq</application> on AIX:
<function>pg_encoding_to_char()</function>,
<function>pg_utf_mblen()</function>,
<function>pg_char_to_encoding()</function>,
<function>pg_valid_server_encoding()</function>, and
<function>pg_valid_server_encoding_id()</function>.
Restore them to visibility.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [fa703b317] 2021-09-13 13:23:50 +0900
Branch: REL_14_STABLE Release: REL_14_0 [cc057fb31] 2021-09-13 13:24:04 +0900
Branch: REL_13_STABLE [b589d212f] 2021-09-13 13:24:20 +0900
Branch: REL_12_STABLE [b34dcf87f] 2021-09-13 13:24:27 +0900
Branch: REL_11_STABLE [b6a10ff4a] 2021-09-13 13:24:35 +0900
Branch: REL_10_STABLE [83a3737a6] 2021-09-13 13:24:47 +0900
Branch: REL9_6_STABLE [3768c468d] 2021-09-13 13:24:56 +0900
-->
<para>
Fix <application>ecpg</application> to recover correctly
after <function>malloc()</function> failure while establishing a
connection (Michael Paquier)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a0558cfa3] 2021-10-03 13:21:20 -0400
Branch: REL_14_STABLE [e0eba586b] 2021-10-03 13:21:20 -0400
-->
<para>
Fix checking of query type in PL/pgSQL's <command>RETURN
QUERY</command> statement (Tom Lane)
</para>
<para>
<command>RETURN QUERY</command> should accept any query that can
return tuples, e.g. <command>UPDATE RETURNING</command>. v14
accidentally disallowed anything but <command>SELECT</command>;
moreover, the <command>RETURN QUERY EXECUTE</command> variant
failed to apply any query-type check at all.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4476bcb87] 2021-09-21 19:06:53 -0400
Branch: REL_14_STABLE Release: REL_14_0 [2ad5f963e] 2021-09-21 19:06:54 -0400
Branch: REL_13_STABLE [5f0a073cb] 2021-09-21 19:06:33 -0400
Branch: REL_12_STABLE [e8b0bcae6] 2021-09-21 19:06:33 -0400
Branch: REL_11_STABLE [13921c511] 2021-09-21 19:06:33 -0400
-->
<para>
Fix misevaluation of stable functions called in the arguments of a
PL/pgSQL <command>CALL</command> statement (Tom Lane)
</para>
<para>
They were being called with an out-of-date snapshot, so that they
would not see any database changes made since the start of the
session's top-level command.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1bf2518dd] 2021-09-13 12:42:03 -0400
Branch: REL_14_STABLE Release: REL_14_0 [4ffd3fe4d] 2021-09-13 12:42:28 -0400
Branch: REL_13_STABLE [745abdd95] 2021-09-13 12:42:03 -0400
Branch: REL_12_STABLE [b1de90699] 2021-09-13 12:42:03 -0400
Branch: REL_11_STABLE [bdd6ce48d] 2021-09-13 12:42:03 -0400
Branch: REL_10_STABLE [fe70ec907] 2021-09-13 12:42:04 -0400
Branch: REL9_6_STABLE [a460f7eb3] 2021-09-13 12:42:04 -0400
-->
<para>
Allow <literal>EXIT</literal> out of the outermost block in a
PL/pgSQL routine (Tom Lane)
</para>
<para>
If the routine does not require an explicit <literal>RETURN</literal>,
this usage should be valid, but it was rejected.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [87ad49147] 2021-09-03 21:04:44 -0400
Branch: REL_14_STABLE Release: REL_14_0 [69d670e68] 2021-09-03 21:04:44 -0400
Branch: REL_13_STABLE [742b30cae] 2021-09-03 21:04:44 -0400
Branch: REL_12_STABLE [3b302eb1e] 2021-09-03 21:04:44 -0400
Branch: REL_11_STABLE [beb404d3b] 2021-09-03 21:04:44 -0400
Branch: REL_10_STABLE [6e2f45817] 2021-09-03 21:04:45 -0400
Branch: REL9_6_STABLE [9a070c658] 2021-09-03 21:04:45 -0400
-->
<para>
Remove <application>pg_ctl</application>'s hard-coded limits on the
total length of generated commands (Phil Krylov)
</para>
<para>
For example, this removes a restriction on how many command-line
options can be passed through to the postmaster. Individual path
names that <application>pg_ctl</application> deals with, such as the
postmaster executable's name or the data directory name, are still
limited to <literal>MAXPGPATH</literal> bytes in most cases.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2acc84c6f] 2021-10-22 15:22:25 -0400
Branch: REL_14_STABLE [3ad2c2455] 2021-10-22 15:22:25 -0400
Branch: REL_13_STABLE [476006023] 2021-10-22 15:22:26 -0400
Branch: REL_12_STABLE [52b927a73] 2021-10-22 15:22:26 -0400
Branch: REL_11_STABLE [871dfe4b7] 2021-10-22 15:22:26 -0400
Branch: REL_10_STABLE [10f9faf6d] 2021-10-22 15:22:26 -0400
Branch: REL9_6_STABLE [b1df061f7] 2021-10-22 15:22:26 -0400
-->
<para>
Fix <application>pg_dump</application> to dump non-global default
privileges correctly (Neil Chen, Masahiko Sawada)
</para>
<para>
If a global (unrestricted) <command>ALTER DEFAULT
PRIVILEGES</command> command revoked some present-by-default
privilege, for example <literal>EXECUTE</literal> for functions, and
then a restricted <command>ALTER DEFAULT PRIVILEGES</command>
command granted that privilege back for a selected role or
schema, <application>pg_dump</application> failed to dump the
restricted privilege grant correctly.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e2ff7d9a8] 2021-10-16 12:23:57 -0400
Branch: REL_14_STABLE [b5152e3ba] 2021-10-16 12:24:11 -0400
Branch: REL_13_STABLE [6a262ba8c] 2021-10-16 12:24:17 -0400
Branch: REL_12_STABLE [fd182a92a] 2021-10-16 12:24:24 -0400
Branch: REL_11_STABLE [ca7a4ce58] 2021-10-16 12:24:33 -0400
Branch: REL_10_STABLE [2e2a23283] 2021-10-16 12:24:40 -0400
-->
<para>
Make <application>pg_dump</application> acquire shared lock on
partitioned tables that are to be dumped (Tom Lane)
</para>
<para>
This oversight was usually pretty harmless, since
once <application>pg_dump</application> has locked any of the leaf
partitions, that would suffice to prevent significant DDL on the
partitioned table itself. However problems could ensue when dumping
a childless partitioned table, since no relevant lock would be held.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [bd3611db5] 2021-08-31 15:04:05 -0400
Branch: REL_14_STABLE Release: REL_14_0 [a20a9f26c] 2021-08-31 15:04:05 -0400
Branch: REL_13_STABLE [db11b4a3d] 2021-08-31 15:04:05 -0400
Branch: REL_12_STABLE [6b9667392] 2021-08-31 15:04:05 -0400
Branch: REL_11_STABLE [a60860ff3] 2021-08-31 15:04:05 -0400
Branch: REL_10_STABLE [ba8f1a0be] 2021-08-31 15:04:05 -0400
Branch: REL9_6_STABLE [dd3105286] 2021-08-31 15:04:05 -0400
Branch: master [6c450a861] 2021-08-31 13:53:49 -0400
Branch: REL_14_STABLE Release: REL_14_0 [9407dbbcb] 2021-08-31 13:53:49 -0400
Branch: REL_13_STABLE [904ce45bf] 2021-08-31 13:53:50 -0400
Branch: REL_12_STABLE [2f1ed9d98] 2021-08-31 13:53:50 -0400
Branch: REL_11_STABLE [c4b298ee1] 2021-08-31 13:53:51 -0400
Branch: REL_10_STABLE [0e7bdc722] 2021-08-31 13:53:51 -0400
Branch: REL9_6_STABLE [4645997c8] 2021-08-31 13:53:33 -0400
-->
<para>
Improve <application>pg_dump</application>'s performance by avoiding
making per-table queries for RLS policies, and by avoiding repetitive
calls to <function>format_type()</function> (Tom Lane)
</para>
<para>
These changes provide only marginal improvement when dumping from a
local server, but a dump from a remote server can benefit
substantially.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [40dfac4fc] 2021-10-16 15:02:55 -0400
Branch: REL_14_STABLE [3e4c8db93] 2021-10-16 15:03:05 -0400
Branch: REL_13_STABLE [0b5f557b7] 2021-10-16 15:03:10 -0400
Branch: REL_12_STABLE [5b0b2983a] 2021-10-16 15:03:15 -0400
Branch: REL_11_STABLE [58955c84f] 2021-10-16 15:03:21 -0400
-->
<para>
Fix crash in <application>pg_dump</application> when attempting to
dump trigger definitions from a pre-8.3 server (Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [998d060f3] 2021-10-19 12:59:54 +0200
Branch: REL_14_STABLE [3e2f32b01] 2021-10-19 12:59:54 +0200
Branch: REL_13_STABLE [687fe8a9d] 2021-10-19 12:59:54 +0200
Branch: REL_12_STABLE [e788883de] 2021-10-19 12:59:54 +0200
Branch: REL_11_STABLE [038892c81] 2021-10-19 12:59:54 +0200
Branch: REL_10_STABLE [4fda03b67] 2021-10-19 12:59:54 +0200
Branch: REL9_6_STABLE [ef1f15819] 2021-10-19 12:59:54 +0200
-->
<para>
Fix incorrect filename in <application>pg_restore</application>'s
error message about an invalid large object TOC file (Daniel
Gustafsson)
</para>
</listitem>
<listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [d33674708] 2021-09-29 21:46:56 +0900
Branch: REL_14_STABLE [8021334d3] 2021-09-29 21:47:25 +0900
Branch: REL_13_STABLE [3cc85d7d5] 2021-09-29 21:47:31 +0900
Branch: master [2acb7cc6b] 2021-09-29 21:48:52 +0900
Branch: REL_14_STABLE [8231c500e] 2021-09-29 21:49:29 +0900
Branch: REL_13_STABLE [8cf4f7118] 2021-09-29 21:49:36 +0900
Branch: REL_12_STABLE [c5f7e702d] 2021-09-29 21:49:40 +0900
-->
<para>
Ensure that <application>pgbench</application> exits with non-zero
status after a socket-level failure (Yugo Nagata, Fabien Coelho)
</para>
<para>
The desired behavior is to finish out the run but then exit with
status 2. Also, fix the reporting of such errors.
</para>
</listitem>
<listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [d2bf06db3] 2021-10-13 14:08:12 -0700
Branch: REL_14_STABLE [dd58194cf] 2021-10-13 14:08:11 -0700
Branch: master [cd3f429d9] 2021-10-14 14:50:26 -0700
Branch: REL_14_STABLE [5863115e4] 2021-10-14 14:50:25 -0700
-->
<para>
Prevent <application>pg_amcheck</application> from checking
temporary relations, as well as indexes that are invalid or not
ready (Mark Dilger)
</para>
<para>
This avoids unhelpful checks of relations that will almost certainly
appear inconsistent.
</para>
</listitem>
<listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [292698f15] 2021-10-11 17:21:48 -0700
Branch: REL_14_STABLE [e7712155e] 2021-10-11 17:21:46 -0700
-->
<para>
Make <filename>contrib/amcheck</filename> skip unlogged tables
when running on a standby server (Mark Dilger)
</para>
<para>
It's appropriate to do this since such tables will be empty,
and unlogged indexes were already handled similarly.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a6bd28beb] 2021-08-10 18:10:29 -0400
Branch: REL_14_STABLE Release: REL_14_0 [a4957b5a7] 2021-08-10 18:10:30 -0400
Branch: REL_13_STABLE [7ba487cf9] 2021-08-10 18:10:30 -0400
Branch: REL_12_STABLE [cd7d9b6b6] 2021-08-10 18:10:30 -0400
Branch: REL_11_STABLE [eefa4c2b5] 2021-08-10 18:10:30 -0400
Branch: REL_10_STABLE [843d2879a] 2021-08-10 18:10:30 -0400
Branch: REL9_6_STABLE [5a9df5d50] 2021-08-10 18:10:30 -0400
-->
<para>
Fix failure of <filename>contrib/btree_gin</filename> indexes
on <type>"char"</type>
(not <type>char(<replaceable>n</replaceable>)</type>) columns,
when an indexscan using the <literal>&lt;</literal>
or <literal>&lt;=</literal> operator is performed (Tom Lane)
</para>
<para>
Such an indexscan failed to return all the entries it should.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a667b0668] 2021-10-31 19:13:48 -0400
Branch: REL_14_STABLE [7104e0b24] 2021-10-31 19:13:48 -0400
Branch: REL_13_STABLE [3a5b313ce] 2021-10-31 19:13:48 -0400
Branch: REL_12_STABLE [16d0da5c8] 2021-10-31 19:13:48 -0400
Branch: REL_11_STABLE [5dd067430] 2021-10-31 19:13:48 -0400
Branch: REL_10_STABLE [d87d5f8d8] 2021-10-31 19:13:48 -0400
Branch: REL9_6_STABLE [fdb60ca83] 2021-10-31 19:13:48 -0400
-->
<para>
Change <filename>contrib/pg_stat_statements</filename> to read
its <quote>query texts</quote> file in units of at most 1GB
(Tom Lane)
</para>
<para>
Such large query text files are very unusual, but if they do occur,
the previous coding would fail on Windows 64 (which rejects
individual read requests of more than 2GB).
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3071bbfe4] 2021-10-06 15:50:24 -0400
Branch: REL_14_STABLE [12ff678e1] 2021-10-06 15:50:24 -0400
Branch: REL_13_STABLE [aee83f39a] 2021-10-06 15:50:24 -0400
Branch: REL_12_STABLE [228897374] 2021-10-06 15:50:24 -0400
Branch: REL_11_STABLE [88807757d] 2021-10-06 15:50:24 -0400
Branch: REL_10_STABLE [2e33fbda1] 2021-10-06 15:50:24 -0400
Branch: REL9_6_STABLE [36c9f7d96] 2021-10-06 15:50:24 -0400
-->
<para>
Fix null-pointer crash
when <filename>contrib/postgres_fdw</filename> tries to report a
data conversion error (Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c32fcac56] 2021-08-13 13:59:43 -0400
Branch: REL_14_STABLE Release: REL_14_0 [4ffbd55d9] 2021-08-13 13:59:44 -0400
Branch: REL_13_STABLE [48695decc] 2021-08-13 13:59:06 -0400
Branch: REL_12_STABLE [cdda2b247] 2021-08-13 13:59:13 -0400
Branch: REL_11_STABLE [8024ff478] 2021-08-13 13:59:18 -0400
Branch: REL_10_STABLE [7915a9515] 2021-08-13 13:59:25 -0400
Branch: REL9_6_STABLE [582a2affa] 2021-08-13 13:59:33 -0400
-->
<para>
Add spinlock support for the RISC-V architecture (Marek Szuba)
</para>
<para>
This is essential for reasonable performance on that platform.
</para>
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master Release: REL_14_BR [22e1943f1] 2021-03-23 11:48:37 +0100
Branch: REL_13_STABLE [a69e1506f] 2021-09-25 11:25:48 +0200
Branch: REL_12_STABLE [90cfd269f] 2021-09-25 11:25:48 +0200
Branch: REL_11_STABLE [0f28d267c] 2021-09-25 11:25:48 +0200
Branch: REL_10_STABLE [841075a65] 2021-09-25 11:25:48 +0200
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [318df8023] 2021-08-10 15:01:52 +0200
Branch: REL_14_STABLE Release: REL_14_0 [4fa2b15e1] 2021-09-25 11:27:20 +0200
Branch: REL_13_STABLE [135d8687a] 2021-09-25 11:27:20 +0200
Branch: REL_12_STABLE [00c72da4a] 2021-09-25 11:27:20 +0200
Branch: REL_11_STABLE [11901cd96] 2021-09-25 11:27:20 +0200
Branch: REL_10_STABLE [e802b594e] 2021-09-25 11:27:20 +0200
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [72bbff4cd] 2021-08-10 15:08:46 +0200
Branch: REL_14_STABLE Release: REL_14_0 [6d0001aab] 2021-09-25 11:27:28 +0200
Branch: REL_13_STABLE [8e7199453] 2021-09-25 11:27:28 +0200
Branch: REL_12_STABLE [7b6ce36fb] 2021-09-25 11:27:28 +0200
Branch: REL_11_STABLE [19e91a40b] 2021-09-25 11:27:28 +0200
Branch: REL_10_STABLE [eb643536b] 2021-09-25 11:27:28 +0200
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [41f30ecc2] 2021-10-20 16:48:24 +0900
Branch: REL_14_STABLE [81aefaea8] 2021-10-20 16:48:57 +0900
Branch: REL_13_STABLE [abb9ee92c] 2021-10-20 16:49:00 +0900
Branch: REL_12_STABLE [1539e0ecd] 2021-10-20 16:49:03 +0900
Branch: REL_11_STABLE [e00d45fea] 2021-10-20 16:49:06 +0900
Branch: REL_10_STABLE [922e3c3b7] 2021-10-20 16:49:10 +0900
Branch: REL9_6_STABLE [d581960df] 2021-10-20 16:49:14 +0900
-->
<para>
Support OpenSSL 3.0.0
(Peter Eisentraut, Daniel Gustafsson, Michael Paquier)
</para>
</listitem>
<listitem>
<!--
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [31f860a52] 2021-08-17 14:30:01 +0200
Branch: REL_14_STABLE Release: REL_14_0 [b88377ad6] 2021-08-17 14:30:25 +0200
Branch: REL_13_STABLE [e15f32f0e] 2021-08-17 14:31:00 +0200
Branch: REL_12_STABLE [ed209db77] 2021-08-17 14:31:08 +0200
Branch: REL_11_STABLE [f1d5a94fc] 2021-08-17 14:30:39 +0200
Branch: REL_10_STABLE [ef7e24ff7] 2021-08-17 14:30:51 +0200
Branch: REL9_6_STABLE [0a88d4ece] 2021-08-17 14:31:22 +0200
-->
<para>
Set correct type identifier on OpenSSL BIO (I/O abstraction)
objects created by <productname>PostgreSQL</productname>
(Itamar Gafni)
</para>
<para>
This oversight probably only matters for code that is doing
tasks like auditing the OpenSSL installation. But it's
nominally a violation of the OpenSSL API, so fix it.
</para>
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [4c2eab3a0] 2021-09-03 10:52:11 +0200
Branch: master [55392bc5b] 2021-09-06 09:12:34 +0200
Branch: REL_14_STABLE Release: REL_14_0 [1e9afc868] 2021-09-06 09:41:03 +0200
Branch: REL_13_STABLE [9f9ae019d] 2021-09-06 09:43:05 +0200
Branch: REL_12_STABLE [60bf7e69b] 2021-09-06 09:43:18 +0200
-->
<para>
Fix our <filename>pkg-config</filename> files to again support static
linking of <application>libpq</application> (Peter Eisentraut)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e757080e0] 2021-09-11 15:19:31 -0400
Branch: REL_14_STABLE Release: REL_14_0 [b33283cbd] 2021-09-11 15:19:43 -0400
Branch: REL_13_STABLE [7e420072e] 2021-09-11 15:19:49 -0400
Branch: REL_12_STABLE [3adde7eb6] 2021-09-11 15:19:54 -0400
Branch: REL_11_STABLE [3be381a90] 2021-09-11 15:19:58 -0400
Branch: REL_10_STABLE [daac97eb0] 2021-09-11 15:20:04 -0400
Branch: REL9_6_STABLE [ec89d7ace] 2021-09-11 15:20:12 -0400
-->
<para>
Make <function>pg_regexec()</function> robust against an
out-of-range <replaceable>search_start</replaceable> parameter
(Tom Lane)
</para>
<para>
Return <literal>REG_NOMATCH</literal>, instead of possibly crashing,
when <replaceable>search_start</replaceable> is past the end of the
string. This case is probably unreachable within
core <productname>PostgreSQL</productname>, but extensions might be
more careless about the parameter value.
</para>
</listitem>
<listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [7821a0bf2] 2021-10-14 12:24:00 -0700
Branch: REL_14_STABLE [0b90f1c4c] 2021-10-14 12:24:22 -0700
Branch: REL_13_STABLE [20f785732] 2021-10-14 12:24:47 -0700
Branch: REL_12_STABLE [ab11f6e46] 2021-10-14 12:25:07 -0700
Branch: REL_11_STABLE [3f5d481ef] 2021-10-14 12:25:30 -0700
Branch: REL_10_STABLE [9364f64a2] 2021-10-14 12:25:48 -0700
Branch: REL9_6_STABLE [ae6abeb88] 2021-10-14 12:26:26 -0700
-->
<para>
Ensure that <function>GetSharedSecurityLabel()</function> can be
used in a newly-started session that has not yet built its critical
relation cache entries (Jeff Davis)
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [f4ce6c4d3] 2021-10-22 09:49:07 -0400
Branch: REL_14_STABLE [52c0c1136] 2021-10-22 09:50:16 -0400
-->
<para>
When running a TAP test, include the module's own directory
in <envar>PATH</envar> (Andrew Dunstan)
</para>
<para>
This allows tests to find built programs that are not installed,
such as custom test drivers.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [937aafd6d] 2021-10-29 11:38:18 -0400
Branch: REL_14_STABLE [0c8a40b39] 2021-10-29 11:38:32 -0400
Branch: REL_13_STABLE [4cd72add0] 2021-10-29 11:38:38 -0400
Branch: REL_12_STABLE [14b8d25d6] 2021-10-29 11:38:47 -0400
Branch: REL_11_STABLE [91455f7c6] 2021-10-29 11:38:53 -0400
Branch: REL_10_STABLE [d0fe211ce] 2021-10-29 11:38:58 -0400
Branch: REL9_6_STABLE [22a498b9b] 2021-10-29 11:39:05 -0400
-->
<para>
Update time zone data files to <application>tzdata</application>
release 2021e for DST law changes in Fiji, Jordan, Palestine, and
Samoa, plus historical corrections for Barbados, Cook Islands,
Guyana, Niue, Portugal, and Tonga.
</para>
<para>
Also, the Pacific/Enderbury zone has been renamed to Pacific/Kanton.
Also, the following zones have been merged into nearby, more-populous
zones whose clocks have agreed with them since 1970: Africa/Accra,
America/Atikokan, America/Blanc-Sablon, America/Creston,
America/Curacao, America/Nassau, America/Port_of_Spain,
Antarctica/DumontDUrville, and Antarctica/Syowa.
In all these cases, the previous zone name remains as an alias.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-14">
<title>Release 14</title>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment