]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
First-draft release notes for 14.1.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 6 Nov 2021 00:26:18 +0000 (20:26 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 6 Nov 2021 00:26:18 +0000 (20:26 -0400)
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.

doc/src/sgml/release-14.sgml

index 51820eac1a37ec4547210c8b3aa1841e1afe444a..d95734e91f60df2b7e58aab99b3b701a92b6114d 100644 (file)
 <!-- 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>