path: root/doc/src/sgml/release-13.sgml

<!-- doc/src/sgml/release-13.sgml -->
<!-- See header comment in release.sgml about typical markup -->

 <sect1 id="release-13-14">
  <title>Release 13.14</title>

  <formalpara>
  <title>Release date:</title>
  <para>2024-02-08</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.13.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.14</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, one bug was fixed that could have resulted in corruption of
    GIN indexes during concurrent updates.  If you suspect such
    corruption, reindex affected indexes after installing this update.
   </para>

   <para>
    Also, if you are upgrading from a version earlier than 13.13,
    see <xref linkend="release-13-13"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [5a9167c39] 2024-02-05 11:01:23 +0200
Branch: REL_16_STABLE [d6a61cb3b] 2024-02-05 11:02:56 +0200
Branch: REL_15_STABLE [f2fdea198] 2024-02-05 11:03:26 +0200
Branch: REL_14_STABLE [f4f288352] 2024-02-05 11:03:43 +0200
Branch: REL_13_STABLE [d541ce3b6] 2024-02-05 11:04:08 +0200
Branch: REL_12_STABLE [2699fc035] 2024-02-05 11:04:22 +0200
Branch: master [b96115acb] 2024-02-05 11:01:30 +0200
Branch: REL_16_STABLE [fb3836855] 2024-02-05 11:03:03 +0200
Branch: REL_15_STABLE [06f36bc01] 2024-02-05 11:03:28 +0200
Branch: REL_14_STABLE [a45c950ae] 2024-02-05 11:03:43 +0200
Branch: REL_13_STABLE [b73d21648] 2024-02-05 11:04:10 +0200
Branch: REL_12_STABLE [add8bc9b8] 2024-02-05 11:04:23 +0200
-->
     <para>
      Tighten security restrictions within <command>REFRESH MATERIALIZED
      VIEW CONCURRENTLY</command> (Heikki Linnakangas)
     </para>

     <para>
      One step of a concurrent refresh command was run under weak security
      restrictions.  If a materialized view's owner could persuade a
      superuser or other high-privileged user to perform a concurrent
      refresh on that view, the view's owner could control code executed
      with the privileges of the user running <command>REFRESH</command>.
      Fix things so that all user-determined code is run as the view's
      owner, as expected.
     </para>

     <para>
      The only known exploit for this error does not work
      in <productname>PostgreSQL</productname> 16.0 and later, so it may
      be that v16 is not vulnerable in practice.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks Pedro
      Gallegos for reporting this problem.
      (CVE-2024-0985) <!-- not CVE-2023-5869 as claimed in commit msg -->
     </para>
    </listitem>

    <listitem>
<!--
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [9dce22033] 2023-09-27 13:02:21 +0200
Branch: REL_16_STABLE [2cf50585e] 2023-11-17 10:18:38 +0100
Branch: REL_15_STABLE [aef521849] 2023-11-17 10:21:34 +0100
Branch: REL_14_STABLE [75a20a4b4] 2023-11-17 10:27:45 +0100
Branch: REL_13_STABLE [10912f7d4] 2023-11-17 11:46:31 +0100
Branch: REL_12_STABLE [3b991f81c] 2023-11-17 11:47:17 +0100
Branch: REL_12_STABLE [c922b2410] 2023-12-11 12:02:01 +0100
-->
     <para>
      Fix memory leak when performing JIT inlining (Andres Freund,
      Daniel Gustafsson)
     </para>

     <para>
      There have been multiple reports of backend processes suffering
      out-of-memory conditions after sufficiently many JIT compilations.
      This fix should resolve that.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: REL_15_STABLE [f374fb4aa] 2024-01-18 11:12:31 +0900
Branch: REL_14_STABLE [5f6ec27a6] 2024-01-18 11:12:38 +0900
Branch: REL_13_STABLE [dc9d424cf] 2024-01-18 11:12:43 +0900
Branch: REL_12_STABLE [810382285] 2024-01-18 11:12:48 +0900
-->
     <para>
      When dequeueing from an LWLock, avoid needing to search the list of
      waiting processes (Andres Freund)
     </para>

     <para>
      This fixes O(N^2) behavior when the list of waiters is long.  In
      some use-cases this results in substantial throughput improvements.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_16_STABLE [62f120203] 2024-02-01 12:34:21 -0500
Branch: REL_15_STABLE [12ec16d11] 2024-02-01 12:34:21 -0500
Branch: REL_14_STABLE [e031995d5] 2024-02-01 12:34:21 -0500
Branch: REL_13_STABLE [7af96a66f] 2024-02-01 12:34:21 -0500
Branch: REL_12_STABLE [2e822a1d6] 2024-02-01 12:34:21 -0500
-->
     <para>
      Avoid generating incorrect partitioned-join plans (Richard Guo)
     </para>

     <para>
      Some uncommon situations involving lateral references could create
      incorrect plans.  Affected queries could produce wrong answers, or
      odd failures such as <quote>variable not found in subplan target
      list</quote>, or executor crashes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [29f114b6f] 2024-01-11 15:28:22 -0500
Branch: REL_16_STABLE [80bece312] 2024-01-11 15:28:13 -0500
Branch: REL_15_STABLE [a0b4fda44] 2024-01-11 15:28:13 -0500
Branch: REL_14_STABLE [ea1d54288] 2024-01-11 15:28:13 -0500
Branch: REL_13_STABLE [bfd28bb07] 2024-01-11 15:28:13 -0500
Branch: REL_12_STABLE [69c12c417] 2024-01-11 15:28:13 -0500
-->
     <para>
      Fix incorrect wrapping of subquery output expressions in
      PlaceHolderVars (Tom Lane)
     </para>

     <para>
      This fixes incorrect results when a subquery is underneath an outer
      join and has an output column that laterally references something
      outside the outer join's scope.  The output column might not appear
      as NULL when it should do so due to the action of the outer join.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [2a67b5a60] 2024-01-07 09:10:19 +0200
Branch: REL_16_STABLE [714a987bc] 2024-01-07 09:32:58 +0200
Branch: REL_15_STABLE [1a7c03e6f] 2024-01-07 09:10:40 +0200
Branch: REL_14_STABLE [3bdaa8fc6] 2024-01-07 09:10:49 +0200
Branch: REL_13_STABLE [60de25c6e] 2024-01-07 09:11:00 +0200
Branch: REL_12_STABLE [72d5b2776] 2024-01-07 09:18:43 +0200
Branch: master [6d94cc6ca] 2024-01-08 20:00:20 +0200
Branch: REL_16_STABLE [20a566cd4] 2024-01-08 19:57:09 +0200
Branch: REL_15_STABLE [6eecc3a62] 2024-01-08 19:57:03 +0200
Branch: REL_14_STABLE [97e64911d] 2024-01-08 19:57:58 +0200
Branch: REL_13_STABLE [17b6f39f1] 2024-01-08 19:58:38 +0200
Branch: REL_12_STABLE [a5e2853c3] 2024-01-08 19:58:51 +0200
-->
     <para>
      Avoid requesting an oversize shared-memory area in parallel hash
      join (Thomas Munro, Andrei Lepikhov, Alexander Korotkov)
     </para>

     <para>
      The limiting value was too large, allowing <quote>invalid DSA memory
      alloc request size</quote> errors to occur with sufficiently large
      expected hash table sizes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [60f227316] 2023-11-28 12:00:14 +0200
Branch: REL_16_STABLE [9fee3232a] 2023-11-28 11:59:45 +0200
Branch: REL_15_STABLE [2873fbfe0] 2023-11-28 11:59:50 +0200
Branch: REL_14_STABLE [59c62a21f] 2023-11-28 11:59:51 +0200
Branch: REL_13_STABLE [e434d3620] 2023-11-28 11:59:52 +0200
Branch: REL_12_STABLE [b8a606e21] 2023-11-28 11:59:53 +0200
-->
     <para>
      Avoid assertion failures in <function>heap_update()</function>
      and <function>heap_delete()</function> when a tuple to be updated by
      a foreign-key enforcement trigger fails the extra visibility
      crosscheck (Alexander Lakhin)
     </para>

     <para>
      This error had no impact in non-assert builds.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [bb812ab09] 2024-01-24 14:20:01 +0900
Branch: REL_16_STABLE [51193e7a7] 2024-01-24 14:20:08 +0900
Branch: REL_15_STABLE [ad6fbbeeb] 2024-01-24 14:20:10 +0900
Branch: REL_14_STABLE [5a7833f49] 2024-01-24 14:20:11 +0900
Branch: REL_13_STABLE [bfec14d06] 2024-01-24 14:20:13 +0900
Branch: REL_12_STABLE [2f7242837] 2024-01-24 14:20:14 +0900
-->
     <para>
      Fix possible failure during <command>ALTER TABLE ADD
      COLUMN</command> on a complex inheritance tree (Tender Wang)
     </para>

     <para>
      If a grandchild table would inherit the new column via multiple
      intermediate parents, the command failed with <quote>tuple already
      updated by self</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [3e91dba8b] 2024-01-31 13:15:21 +0900
Branch: REL_16_STABLE [f33e83285] 2024-01-31 13:16:43 +0900
Branch: REL_15_STABLE [41fa4b31c] 2024-01-31 13:16:46 +0900
Branch: REL_14_STABLE [dde5b01c3] 2024-01-31 13:16:47 +0900
Branch: REL_13_STABLE [4d0e8a008] 2024-01-31 13:16:49 +0900
Branch: REL_12_STABLE [056109782] 2024-01-31 13:16:50 +0900
-->
     <para>
      Fix problems with duplicate token names in <command>ALTER TEXT
      SEARCH CONFIGURATION ... MAPPING</command> commands (Tender Wang,
      Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [28f84f72f] 2023-11-19 21:03:38 +0100
Branch: REL_16_STABLE [ee32b824d] 2023-11-19 21:03:50 +0100
Branch: REL_15_STABLE [0177fc773] 2023-11-19 21:04:16 +0100
Branch: REL_14_STABLE [9dd50e92e] 2023-11-19 21:04:28 +0100
Branch: REL_13_STABLE [1e468ea4e] 2023-11-19 21:04:39 +0100
Branch: REL_12_STABLE [4f8d3c5b5] 2023-11-19 21:04:47 +0100
-->
     <para>
      Properly lock the associated table during <command>DROP
      STATISTICS</command> (Tomas Vondra)
     </para>

     <para>
      Failure to acquire the lock could result in <quote>tuple
      concurrently deleted</quote> errors if the <command>DROP</command>
      executes concurrently with <command>ANALYZE</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [743ddafc7] 2023-11-16 10:05:14 -0500
Branch: REL_16_STABLE [f07a3039c] 2023-11-16 10:05:14 -0500
Branch: REL_15_STABLE [9057ddbef] 2023-11-16 10:05:14 -0500
Branch: REL_14_STABLE [9bd0f74ea] 2023-11-16 10:05:14 -0500
Branch: REL_13_STABLE [5c11104c7] 2023-11-16 10:05:14 -0500
Branch: REL_12_STABLE [abd1b1325] 2023-11-16 10:05:14 -0500
-->
     <para>
      Fix function volatility checking for <literal>GENERATED</literal>
      and <literal>DEFAULT</literal> expressions (Tom Lane)
     </para>

     <para>
      These places could fail to detect insertion of a volatile function
      default-argument expression, or decide that a polymorphic function
      is volatile although it is actually immutable on the datatype of
      interest.  This could lead to improperly rejecting or accepting
      a <literal>GENERATED</literal> clause, or to mistakenly applying the
      constant-default-value optimization in <command>ALTER TABLE ADD
      COLUMN</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ad98fb142] 2024-01-13 13:46:27 -0500
Branch: REL_16_STABLE [7e2561e1a] 2024-01-13 13:46:27 -0500
Branch: REL_15_STABLE [2a46a0df4] 2024-01-13 13:46:27 -0500
Branch: REL_14_STABLE [db122d426] 2024-01-13 13:46:27 -0500
Branch: REL_13_STABLE [98e03f957] 2024-01-13 13:46:27 -0500
Branch: REL_12_STABLE [3b4d85cf1] 2024-01-13 13:46:27 -0500
Branch: master [96c019ffa] 2024-01-13 13:54:11 -0500
Branch: REL_16_STABLE [56dcd71de] 2024-01-13 13:54:11 -0500
Branch: REL_15_STABLE [d41358f4b] 2024-01-13 13:54:11 -0500
Branch: REL_14_STABLE [7ceeb57ba] 2024-01-13 13:54:11 -0500
Branch: REL_13_STABLE [475b3ea3c] 2024-01-13 13:54:11 -0500
Branch: REL_12_STABLE [d29a4fbac] 2024-01-13 13:54:11 -0500
-->
     <para>
      Detect that a new catalog cache entry became stale while detoasting
      its fields (Tom Lane)
     </para>

     <para>
      We expand any out-of-line fields in a catalog tuple before inserting
      it into the catalog caches.  That involves database access which
      might cause invalidation of catalog cache entries &mdash; but the
      new entry isn't in the cache yet, so we would miss noticing that it
      should get invalidated.  The result is a race condition in which an
      already-stale cache entry could get made, and then persist
      indefinitely.  This would lead to hard-to-predict misbehavior.
      Fix by rechecking the tuple's visibility after detoasting.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [0e3e8fbd3] 2023-11-09 09:50:23 +0000
Branch: REL_16_STABLE [c396aca2b] 2023-11-09 09:53:05 +0000
Branch: REL_15_STABLE [308a69a98] 2023-11-09 09:54:22 +0000
Branch: REL_14_STABLE [dea12b40d] 2023-11-09 09:55:39 +0000
Branch: REL_13_STABLE [4f4a0010a] 2023-11-09 09:56:31 +0000
Branch: REL_12_STABLE [b17a02be2] 2023-11-09 09:57:52 +0000
-->
     <para>
      Fix edge-case integer overflow detection bug on some platforms (Dean
      Rasheed)
     </para>

     <para>
      Computing <literal>0 - INT64_MIN</literal> should result in an
      overflow error, and did on most platforms.  However, platforms with
      neither integer overflow builtins nor 128-bit integers would fail to
      spot the overflow, instead returning <literal>INT64_MIN</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [25cd2d640] 2024-01-26 13:39:45 -0500
Branch: REL_16_STABLE [7204aea83] 2024-01-26 13:39:37 -0500
Branch: REL_15_STABLE [86b6243a8] 2024-01-26 13:39:37 -0500
Branch: REL_14_STABLE [3eb8a87f6] 2024-01-26 13:39:37 -0500
Branch: REL_13_STABLE [425127bed] 2024-01-26 13:39:37 -0500
Branch: REL_12_STABLE [c3bdb25fb] 2024-01-26 13:39:37 -0500
-->
     <para>
      Detect Julian-date overflow when adding or subtracting
      an <type>interval</type> to/from a <type>timestamp</type> (Tom Lane)
     </para>

     <para>
      Some cases that should cause an out-of-range error produced an
      incorrect result instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [b218fbb7a] 2023-11-18 14:41:20 +0000
Branch: REL_16_STABLE [72d0c135b] 2023-11-18 14:46:02 +0000
Branch: REL_15_STABLE [2851aa7d1] 2023-11-18 14:47:04 +0000
Branch: REL_14_STABLE [2ffcebdba] 2023-11-18 14:48:10 +0000
Branch: REL_13_STABLE [428770aad] 2023-11-18 14:49:18 +0000
Branch: REL_12_STABLE [f499d2b20] 2023-11-18 14:50:00 +0000
-->
     <para>
      Add more checks for overflow in <function>interval_mul()</function>
      and <function>interval_div()</function> (Dean Rasheed)
     </para>

     <para>
      Some cases that should cause an out-of-range error produced an
      incorrect result instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [059de3ca4] 2023-12-26 17:57:48 -0500
Branch: REL_16_STABLE [e87252ceb] 2023-12-26 17:57:48 -0500
Branch: REL_15_STABLE [76dd3d94a] 2023-12-26 17:57:48 -0500
Branch: REL_14_STABLE [bf4f30a0f] 2023-12-26 17:57:48 -0500
Branch: REL_13_STABLE [cb88f44ec] 2023-12-26 17:57:48 -0500
Branch: REL_12_STABLE [ea61b1cf6] 2023-12-26 17:57:48 -0500
-->
     <para>
      Make the <structname>pg_file_settings</structname> view check
      validity of unapplied values for settings
      with <literal>backend</literal>
      or <literal>superuser-backend</literal> context (Tom Lane)
     </para>

     <para>
      Invalid values were not noted in the view as intended.  This escaped
      detection because there are very few settings in these groups.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [a11c9c42e] 2023-12-01 16:05:41 +0100
Branch: REL_16_STABLE [267f33f68] 2023-12-01 16:09:54 +0100
Branch: REL_15_STABLE [15d485921] 2023-12-01 16:14:22 +0100
Branch: REL_14_STABLE [e846fc491] 2023-12-01 16:17:38 +0100
Branch: REL_13_STABLE [3c49fa2af] 2023-12-01 16:23:18 +0100
Branch: REL_12_STABLE [5d40b3c4f] 2023-12-01 16:27:18 +0100
-->
     <para>
      Match collation too when matching an existing index to a new
      partitioned index (Peter Eisentraut)
     </para>

     <para>
      Previously we could accept an index that has a different collation
      from the corresponding element of the partition key, possibly
      leading to misbehavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [6a1ea02c4] 2024-01-29 13:46:22 +0200
Branch: REL_16_STABLE [b899e00e7] 2024-01-29 13:46:30 +0200
Branch: REL_15_STABLE [e43425f48] 2024-01-29 13:46:42 +0200
Branch: REL_14_STABLE [f120c0872] 2024-01-29 13:46:43 +0200
Branch: REL_13_STABLE [e74c91665] 2024-01-29 13:46:45 +0200
Branch: REL_12_STABLE [e6511fe64] 2024-01-29 13:46:48 +0200
-->
     <para>
      Fix insufficient locking when cleaning up an incomplete split of
      a GIN index's internal page (Fei Changhong, Heikki Linnakangas)
     </para>

     <para>
      The code tried to do this with shared rather than exclusive lock on
      the buffer.  This could lead to index corruption if two processes
      attempted the cleanup concurrently.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5c62ecf6e] 2023-11-13 11:44:35 -0500
Branch: REL_16_STABLE [f76b975d5] 2023-11-13 11:44:48 -0500
Branch: REL_15_STABLE [4c73ec604] 2023-11-13 11:44:57 -0500
Branch: REL_14_STABLE [d900e74e0] 2023-11-13 11:45:04 -0500
Branch: REL_13_STABLE [c859d688b] 2023-11-13 11:45:09 -0500
Branch: REL_12_STABLE [5a6937ec9] 2023-11-13 11:45:13 -0500
-->
     <para>
      Avoid premature release of buffer pin in GIN index insertion
      (Tom Lane)
     </para>

     <para>
      If an index root page split occurs concurrently with our own
      insertion, the code could fail with <quote>buffer NNNN is not owned
      by resource owner</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [903737c5b] 2023-12-21 12:43:36 -0500
Branch: REL_16_STABLE [0977bd64e] 2023-12-21 12:43:36 -0500
Branch: REL_15_STABLE [ab04c1901] 2023-12-21 12:43:36 -0500
Branch: REL_14_STABLE [375f441bd] 2023-12-21 12:43:36 -0500
Branch: REL_13_STABLE [cc3865150] 2023-12-21 12:43:36 -0500
Branch: REL_12_STABLE [1771ec9a8] 2023-12-21 12:43:36 -0500
-->
     <para>
      Avoid failure with partitioned SP-GiST indexes (Tom Lane)
     </para>

     <para>
      Trying to use an index of this kind could lead to <quote>No such
      file or directory</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [59bd34c2f] 2023-12-15 13:55:05 -0500
Branch: REL_16_STABLE [152bfc0af] 2023-12-15 13:55:05 -0500
Branch: REL_15_STABLE [7a99fb6e1] 2023-12-15 13:55:05 -0500
Branch: REL_14_STABLE [f552f2be2] 2023-12-15 13:55:05 -0500
Branch: REL_13_STABLE [55b5c67da] 2023-12-15 13:55:05 -0500
Branch: REL_12_STABLE [ba66f2533] 2023-12-15 13:55:05 -0500
-->
     <para>
      Fix ownership change reporting for large objects (Tom Lane)
     </para>

     <para>
      A no-op <command>ALTER LARGE OBJECT OWNER</command> command (that
      is, one selecting the existing owner) passed the wrong class ID to
      the <varname>PostAlterHook</varname>, probably confusing any
      extension using that hook.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [8a7cbfce1] 2023-12-12 17:05:18 +0100
Branch: REL_16_STABLE [0e2c05af9] 2023-12-12 17:05:27 +0100
Branch: REL_15_STABLE [f5d8f59ca] 2023-12-12 17:05:29 +0100
Branch: REL_14_STABLE [0cfd3ddfe] 2023-12-12 17:05:33 +0100
Branch: REL_13_STABLE [d99294e77] 2023-12-12 17:05:34 +0100
Branch: REL_12_STABLE [4d45ecc92] 2023-12-12 17:05:36 +0100
-->
     <para>
      Prevent standby servers from incorrectly processing dead index
      tuples during subtransactions (Fei Changhong)
     </para>

     <para>
      The <structfield>startedInRecovery</structfield> flag was not
      correctly set for a subtransaction.  This affects only processing of
      dead index tuples.  It could allow a query in a subtransaction to
      ignore index entries that it should return (if they are already dead
      on the primary server, but not dead to the standby transaction), or
      to prematurely mark index entries as dead that are not yet dead on
      the primary.  It is not clear that the latter case has any serious
      consequences, but it's not the intended behavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [8d7d2197f] 2023-12-11 08:50:43 +0530
Branch: REL_16_STABLE [01cc92fa6] 2023-12-11 08:36:17 +0530
Branch: REL_15_STABLE [332b43063] 2023-12-11 08:23:33 +0530
Branch: REL_14_STABLE [3f86867d5] 2023-12-11 08:10:46 +0530
Branch: REL_13_STABLE [b47ea4f3d] 2023-12-11 07:57:50 +0530
Branch: REL_12_STABLE [e81e617f3] 2023-12-11 07:45:45 +0530
-->
     <para>
      Fix deadlock between a logical replication apply worker, its
      tablesync worker, and a session process trying to alter the
      subscription (Shlok Kyal)
     </para>

     <para>
      One edge of the deadlock loop did not involve a lock wait, so the
      deadlock went undetected and would persist until manual
      intervention.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [aaf09c592] 2024-01-03 17:40:41 -0500
Branch: REL_16_STABLE [fb464a1ae] 2024-01-03 17:40:38 -0500
Branch: REL_15_STABLE [a0d016393] 2024-01-03 17:40:38 -0500
Branch: REL_14_STABLE [9b042e27e] 2024-01-03 17:40:38 -0500
Branch: REL_13_STABLE [5810888c5] 2024-01-03 17:40:38 -0500
Branch: REL_12_STABLE [c20f2aab6] 2024-01-03 17:40:38 -0500
-->
     <para>
      Return the correct status code when a new client disconnects without
      responding to the server's password challenge (Liu Lang, Tom Lane)
     </para>

     <para>
      In some cases we'd treat this as a loggable error, which was not the
      intention and tends to create log spam, since common clients
      like <application>psql</application> frequently do this.  It may
      also confuse extensions that
      use <varname>ClientAuthentication_hook</varname>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c82207a54] 2023-11-28 12:34:03 -0500
Branch: REL_16_STABLE [efa8f6064] 2023-11-28 12:34:03 -0500
Branch: REL_15_STABLE [5dd30bb54] 2023-11-28 12:34:03 -0500
Branch: REL_14_STABLE [b2b1f1288] 2023-11-28 12:34:03 -0500
Branch: REL_13_STABLE [efb804682] 2023-11-28 12:34:03 -0500
Branch: REL_12_STABLE [0bd682246] 2023-11-28 12:34:03 -0500
-->
     <para>
      Fix incompatibility with <application>OpenSSL</application> 3.2
      (Tristan Partin, Bo Andreson)
     </para>

     <para>
      Use the BIO <quote>app_data</quote> field for our private storage,
      instead of assuming it's okay to use the <quote>data</quote> field.
      This mistake didn't cause problems before, but with 3.2 it leads
      to crashes and complaints about double frees.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0a5c46a7a] 2023-12-11 11:51:56 -0500
Branch: REL_16_STABLE [ebbd499d4] 2023-12-11 11:51:56 -0500
Branch: REL_15_STABLE [551d4b28e] 2023-12-11 11:51:56 -0500
Branch: REL_14_STABLE [07ce24326] 2023-12-11 11:51:56 -0500
Branch: REL_13_STABLE [87b46ad90] 2023-12-11 11:51:56 -0500
Branch: REL_12_STABLE [271d24f31] 2023-12-11 11:51:56 -0500
-->
     <para>
      Be more wary about <application>OpenSSL</application> not
      setting <varname>errno</varname> on error (Tom Lane)
     </para>

     <para>
      If <varname>errno</varname> isn't set, assume the cause of the
      reported failure is read EOF.  This fixes rare cases of strange
      error reports like <quote>could not accept SSL connection:
      Success</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e4e63cd98] 2024-02-02 15:34:29 -0500
Branch: REL_16_STABLE [a15378100] 2024-02-02 15:34:29 -0500
Branch: REL_15_STABLE [3766b8b64] 2024-02-02 15:34:29 -0500
Branch: REL_14_STABLE [329b96882] 2024-02-02 15:34:29 -0500
Branch: REL_13_STABLE [29df29dad] 2024-02-02 15:34:29 -0500
Branch: REL_12_STABLE [4493bfb70] 2024-02-02 15:34:29 -0500
-->
     <para>
      Report <systemitem>ENOMEM</systemitem> errors from file-related system
      calls as <literal>ERRCODE_OUT_OF_MEMORY</literal>,
      not <literal>ERRCODE_INTERNAL_ERROR</literal> (Alexander Kuzmenkov)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [01eca6a91] 2023-11-27 09:40:44 +0900
Branch: REL_16_STABLE [8984480b5] 2023-11-27 09:40:49 +0900
Branch: REL_15_STABLE [b97226815] 2023-11-27 09:40:50 +0900
Branch: REL_14_STABLE [c3b79223f] 2023-11-27 09:40:52 +0900
Branch: REL_13_STABLE [09f680d11] 2023-11-27 09:40:55 +0900
Branch: REL_12_STABLE [0217a7444] 2023-11-27 09:40:57 +0900
-->
     <para>
      Avoid race condition when <application>libpq</application>
      initializes OpenSSL support concurrently in two different threads
      (Willi Mann, Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d053a879b] 2023-11-23 13:30:18 -0500
Branch: REL_16_STABLE [85eb77185] 2023-11-23 13:30:18 -0500
Branch: REL_15_STABLE [a50053777] 2023-11-23 13:30:18 -0500
Branch: REL_14_STABLE [8f23e6a45] 2023-11-23 13:30:18 -0500
Branch: REL_13_STABLE [5abdfd88f] 2023-11-23 13:30:18 -0500
Branch: REL_12_STABLE [18fad508b] 2023-11-23 13:30:19 -0500
-->
     <para>
      Fix timing-dependent failure in GSSAPI data transmission (Tom Lane)
     </para>

     <para>
      When using GSSAPI encryption in non-blocking
      mode, <application>libpq</application> sometimes failed
      with <quote>GSSAPI caller failed to retransmit all data needing to
      be retried</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a70f2a57f] 2023-11-13 17:04:26 -0500
Branch: REL_16_STABLE [64d2467fc] 2023-11-13 17:04:26 -0500
Branch: REL_15_STABLE [f15147df6] 2023-11-13 17:04:10 -0500
Branch: REL_14_STABLE [15439205d] 2023-11-13 17:04:10 -0500
Branch: REL_13_STABLE [9e08789d4] 2023-11-13 17:04:10 -0500
Branch: REL_12_STABLE [891afa84c] 2023-11-13 17:04:10 -0500
Branch: master [1e3f461e8] 2023-11-14 00:31:39 -0500
Branch: REL_16_STABLE [f1674ac6b] 2023-11-14 00:31:39 -0500
Branch: REL_15_STABLE [63c1b4d88] 2023-11-14 00:31:39 -0500
Branch: REL_14_STABLE [c532be99d] 2023-11-14 00:31:39 -0500
Branch: REL_13_STABLE [7836f6838] 2023-11-14 00:31:39 -0500
Branch: REL_12_STABLE [e43790342] 2023-11-14 00:31:39 -0500
-->
     <para>
      In <application>pg_dump</application>, don't dump RLS policies or
      security labels for extension member objects (Tom Lane, Jacob
      Champion)
     </para>

     <para>
      Previously, commands would be included in the dump to set these
      properties, which is really incorrect since they should be
      considered as internal affairs of the extension.  Moreover, the
      restoring user might not have adequate privilege to set them, and
      indeed the dumping user might not have enough privilege to dump them
      (since dumping RLS policies requires acquiring lock on their table).
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7418767f1] 2023-12-29 10:57:11 -0500
Branch: REL_16_STABLE [b2c9936a7] 2023-12-29 10:57:11 -0500
Branch: REL_15_STABLE [1e0841426] 2023-12-29 10:57:11 -0500
Branch: REL_14_STABLE [aa2e323ee] 2023-12-29 10:57:11 -0500
Branch: REL_13_STABLE [8d4e8b746] 2023-12-29 10:57:11 -0500
Branch: REL_12_STABLE [69d7edb06] 2023-12-29 10:57:11 -0500
-->
     <para>
      In <application>pg_dump</application>, don't dump an extended
      statistics object if its underlying table isn't being dumped
      (Rian McGuire, Tom Lane)
     </para>

     <para>
      This conforms to the behavior for other dependent objects such as
      indexes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9034a2d51] 2024-01-07 15:19:50 -0500
Branch: REL_16_STABLE [cf6f802bf] 2024-01-07 15:19:50 -0500
Branch: REL_15_STABLE [940ab02b5] 2024-01-07 15:19:50 -0500
Branch: REL_14_STABLE [90e8b86fc] 2024-01-07 15:19:50 -0500
Branch: REL_13_STABLE [9e7432faf] 2024-01-07 15:19:50 -0500
Branch: REL_12_STABLE [1c7443521] 2024-01-07 15:19:50 -0500
-->
     <para>
      Fix crash in <filename>contrib/intarray</filename> if an array with
      an element equal to <literal>INT_MAX</literal> is inserted into
      a <literal>gist__int_ops</literal> index
      (Alexander Lakhin, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [208470136] 2023-12-19 18:19:05 +0900
Branch: REL_16_STABLE [7f68b1462] 2023-12-19 18:19:15 +0900
Branch: REL_15_STABLE [2e08440d6] 2023-12-19 18:19:16 +0900
Branch: REL_14_STABLE [bfbe4a146] 2023-12-19 18:19:18 +0900
Branch: REL_13_STABLE [586c6a091] 2023-12-19 18:19:19 +0900
Branch: REL_12_STABLE [f610d4f11] 2023-12-19 18:19:21 +0900
-->
     <para>
      Report a better error
      when <filename>contrib/pageinspect</filename>'s
      <function>hash_bitmap_info()</function> function is applied to a
      partitioned hash index (Alexander Lakhin, Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [a8dd62ef4] 2023-12-19 15:20:39 +0900
Branch: REL_16_STABLE [b4948ed66] 2023-12-19 15:20:48 +0900
Branch: REL_15_STABLE [b745f1680] 2023-12-19 15:20:50 +0900
Branch: REL_14_STABLE [f729fdab4] 2023-12-19 15:20:52 +0900
Branch: REL_13_STABLE [b4c1d255c] 2023-12-19 15:20:53 +0900
Branch: REL_12_STABLE [bd2d3c928] 2023-12-19 15:20:55 +0900
-->
     <para>
      Report a better error
      when <filename>contrib/pgstattuple</filename>'s
      <function>pgstathashindex()</function> function is applied to a
      partitioned hash index (Alexander Lakhin)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [9886744a3] 2024-01-10 10:41:57 +0900
Branch: REL_16_STABLE [714bfb781] 2024-01-12 13:53:07 +0900
Branch: REL_15_STABLE [33d1be06a] 2024-01-12 13:53:10 +0900
Branch: REL_14_STABLE [4c6944223] 2024-01-12 13:53:12 +0900
Branch: REL_13_STABLE [c8aab699e] 2024-01-12 13:53:13 +0900
Branch: REL_12_STABLE [9e70e6564] 2024-01-12 13:53:14 +0900
Branch: master [b83747a8a] 2024-01-11 10:39:58 +0900
Branch: REL_16_STABLE [506c77f9b] 2024-01-12 13:59:51 +0900
Branch: REL_15_STABLE [7e7d827f5] 2024-01-12 13:59:58 +0900
Branch: REL_14_STABLE [4a7475e9a] 2024-01-12 14:00:00 +0900
Branch: REL_13_STABLE [2a0eb80ae] 2024-01-12 14:00:01 +0900
Branch: REL_12_STABLE [e50a52b2b] 2024-01-12 14:00:02 +0900
-->
     <para>
      On Windows, suppress autorun options when launching subprocesses
      in <application>pg_ctl</application>
      and <application>pg_regress</application> (Kyotaro Horiguchi)
     </para>

     <para>
      When launching a child process via <filename>cmd.exe</filename>,
      pass the <option>/D</option> flag to prevent executing any autorun
      commands specified in the registry.  This avoids possibly-surprising
      side effects.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [400928b83] 2024-01-29 12:06:13 -0500
Branch: REL_16_STABLE [e02fea093] 2024-01-29 12:06:07 -0500
Branch: REL_15_STABLE [3f8ac13b1] 2024-01-29 12:06:07 -0500
Branch: REL_14_STABLE [29e25a6b1] 2024-01-29 12:06:08 -0500
Branch: REL_13_STABLE [7c53b1977] 2024-01-29 12:06:08 -0500
Branch: REL_12_STABLE [b2fd1dab9] 2024-01-29 12:06:08 -0500
-->
     <para>
      Fix compilation failures with <application>libxml2</application>
      version 2.12.0 and later (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [7636725b9] 2023-12-06 14:10:39 +0900
Branch: REL_16_STABLE [6248a2bb9] 2023-12-06 14:11:41 +0900
Branch: REL_15_STABLE [87ed81a87] 2023-12-06 14:11:44 +0900
Branch: REL_14_STABLE [c49b6cab1] 2023-12-06 14:11:46 +0900
Branch: REL_13_STABLE [7d5a74033] 2023-12-06 14:11:47 +0900
-->
     <para>
      Fix compilation failure of <literal>WAL_DEBUG</literal> code on
      Windows (Bharath Rupireddy)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [58c3151bb] 2023-12-26 16:16:37 -0500
Branch: REL_16_STABLE [b0115e7e2] 2023-12-26 16:16:29 -0500
Branch: REL_15_STABLE [5f8d6d709] 2023-12-26 16:16:29 -0500
Branch: REL_14_STABLE [7978eee02] 2023-12-26 16:16:29 -0500
Branch: REL_13_STABLE [48e797164] 2023-12-26 16:16:29 -0500
Branch: REL_12_STABLE [1613e2fae] 2023-12-26 16:16:29 -0500
Branch: master [a46972e30] 2023-12-26 17:03:02 -0500
Branch: REL_16_STABLE [c72049dbc] 2023-12-26 17:03:24 -0500
-->
     <para>
      Suppress compiler warnings from Python's header files
      (Peter Eisentraut, Tom Lane)
     </para>

     <para>
      Our preferred compiler options provoke warnings about constructs
      appearing in recent versions of Python's header files.  When using
      <application>gcc</application>, we can suppress these warnings with
      a pragma.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [d282e88e5] 2024-01-25 13:44:54 +1300
Branch: REL_16_STABLE [60ba7cae7] 2024-01-25 13:45:22 +1300
Branch: REL_15_STABLE [67f7aaa38] 2024-01-25 13:46:07 +1300
Branch: REL_14_STABLE [364283c92] 2024-01-25 13:46:38 +1300
Branch: REL_13_STABLE [70a82f40a] 2024-01-25 13:47:20 +1300
Branch: REL_12_STABLE [d060cb658] 2024-01-25 13:47:35 +1300
-->
     <para>
      Avoid deprecation warning when compiling with LLVM 18 (Thomas Munro)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [272a7c303] 2024-02-01 15:57:53 -0500
Branch: REL_16_STABLE [b4fb76fb5] 2024-02-01 15:57:53 -0500
Branch: REL_15_STABLE [970b1aeeb] 2024-02-01 15:57:53 -0500
Branch: REL_14_STABLE [35b8b2c4a] 2024-02-01 15:57:53 -0500
Branch: REL_13_STABLE [ac3afc3f7] 2024-02-01 15:57:53 -0500
Branch: REL_12_STABLE [b59ae79b7] 2024-02-01 15:57:53 -0500
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2024a for DST law changes in Greenland, Kazakhstan, and
      Palestine, plus corrections for the Antarctic stations Casey and
      Vostok.  Also historical corrections for Vietnam, Toronto, and
      Miquelon.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-13">
  <title>Release 13.13</title>

  <formalpara>
  <title>Release date:</title>
  <para>2023-11-09</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.12.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.13</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, several mistakes have been discovered that could lead to
    certain types of indexes yielding wrong search results.
    It is advisable
    to <command>REINDEX</command> potentially-affected indexes after
    installing this update.  See the fourth and fifth changelog
    entries below.
   </para>

   <para>
    Also, if you are upgrading from a version earlier than 13.12,
    see <xref linkend="release-13-12"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3b0776fde] 2023-11-06 10:38:00 -0500
Branch: REL_16_STABLE [d3d1e2509] 2023-11-06 10:38:00 -0500
Branch: REL_15_STABLE [4f4a422fb] 2023-11-06 10:38:00 -0500
Branch: REL_14_STABLE [9146d0d65] 2023-11-06 10:38:00 -0500
Branch: REL_13_STABLE [d3de70fdb] 2023-11-06 10:38:00 -0500
Branch: REL_12_STABLE [e911afd09] 2023-11-06 10:38:00 -0500
Branch: REL_11_STABLE [8c6633f4d] 2023-11-06 10:38:00 -0500
-->
     <para>
      Fix handling of unknown-type arguments
      in <literal>DISTINCT</literal> <type>"any"</type> aggregate
      functions (Tom Lane)
     </para>

     <para>
      This error led to a <type>text</type>-type value being interpreted
      as an <type>unknown</type>-type value (that is, a zero-terminated
      string) at runtime.  This could result in disclosure of server
      memory following the <type>text</type> value.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks Jingzhou Fu
      for reporting this problem.
      (CVE-2023-5868)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [18b585155] 2023-11-06 10:56:43 -0500
Branch: REL_16_STABLE [e24daa94b] 2023-11-06 10:56:43 -0500
Branch: REL_15_STABLE [3bc6bc3ee] 2023-11-06 10:56:43 -0500
Branch: REL_14_STABLE [edc0a8d82] 2023-11-06 10:56:43 -0500
Branch: REL_13_STABLE [26c599beb] 2023-11-06 10:56:43 -0500
Branch: REL_12_STABLE [d267cea24] 2023-11-06 10:56:43 -0500
Branch: REL_11_STABLE [c48008f59] 2023-11-06 10:56:43 -0500
-->
     <para>
      Detect integer overflow while computing new array dimensions
      (Tom Lane)
     </para>

     <para>
      When assigning new elements to array subscripts that are outside the
      current array bounds, an undetected integer overflow could occur in
      edge cases.  Memory stomps that are potentially exploitable for
      arbitrary code execution are possible, and so is disclosure of
      server memory.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks Pedro
      Gallegos for reporting this problem.
      (CVE-2023-5869)
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [3a9b18b30] 2023-11-06 06:14:13 -0800
Branch: REL_16_STABLE [785412731] 2023-11-06 06:14:16 -0800
Branch: REL_15_STABLE [595c988c9] 2023-11-06 06:14:16 -0800
Branch: REL_14_STABLE [508acb901] 2023-11-06 06:14:17 -0800
Branch: REL_13_STABLE [28b609550] 2023-11-06 06:14:17 -0800
Branch: REL_12_STABLE [2893f2f40] 2023-11-06 06:14:17 -0800
Branch: REL_11_STABLE [e082734c8] 2023-11-06 06:14:18 -0800
Author: Noah Misch <noah@leadboat.com>
Branch: master [b72de09a1] 2023-11-06 06:14:13 -0800
Branch: REL_16_STABLE [2c3c5ec49] 2023-11-06 06:14:16 -0800
Branch: REL_15_STABLE [fbc371909] 2023-11-06 06:14:16 -0800
Branch: REL_14_STABLE [ecd5d240c] 2023-11-06 06:14:17 -0800
Branch: REL_13_STABLE [2c7a2a00a] 2023-11-06 06:14:17 -0800
Branch: REL_12_STABLE [7bbf4d037] 2023-11-06 06:14:17 -0800
Branch: REL_11_STABLE [a27be40c1] 2023-11-06 06:14:18 -0800
-->
     <para>
      Prevent the <literal>pg_signal_backend</literal> role from
      signalling background workers and autovacuum processes
      (Noah Misch, Jelte Fennema-Nio)
     </para>

     <para>
      The documentation says that <literal>pg_signal_backend</literal>
      cannot issue signals to superuser-owned processes.  It was able to
      signal these background processes, though, because they advertise a
      role OID of zero.  Treat that as indicating superuser ownership.
      The security implications of cancelling one of these process types
      are fairly small so far as the core code goes (we'll just start
      another one), but extensions might add background workers that are
      more vulnerable.
     </para>

     <para>
      Also ensure that the <varname>is_superuser</varname> parameter is
      set correctly in such processes.  No specific security consequences
      are known for that oversight, but it might be significant for some
      extensions.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Hemanth Sandrana and Mahendrakar Srinivasarao
      for reporting this problem.
      (CVE-2023-5870)
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [28d3c2ddc] 2023-09-26 14:14:49 +0300
Branch: REL_16_STABLE [d7f521325] 2023-09-26 14:15:01 +0300
Branch: REL_15_STABLE [c3c284b37] 2023-09-26 14:15:19 +0300
Branch: REL_14_STABLE [747cef5a5] 2023-09-26 14:15:28 +0300
Branch: REL_13_STABLE [db7394d4d] 2023-09-26 14:15:35 +0300
Branch: REL_12_STABLE [26917ebea] 2023-09-26 15:41:44 +0300
-->
     <para>
      Fix misbehavior during recursive page split in GiST index build
      (Heikki Linnakangas)
     </para>

     <para>
      Fix a case where the location of a page downlink was incorrectly
      tracked, and introduce some logic to allow recovering from such
      situations rather than silently doing the wrong thing.  This error
      could result in incorrect answers from subsequent index searches.
      It may be advisable to reindex all GiST indexes after installing
      this update.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [5f27b5f84] 2023-10-14 16:33:51 -0700
Branch: REL_16_STABLE [bf1c21c4f] 2023-10-14 16:33:54 -0700
Branch: REL_15_STABLE [782be0f71] 2023-10-14 16:33:54 -0700
Branch: REL_14_STABLE [0834df909] 2023-10-14 16:33:54 -0700
Branch: REL_13_STABLE [6fd1dbdb2] 2023-10-14 16:33:54 -0700
-->
     <para>
      Prevent de-duplication of btree index entries
      for <type>interval</type> columns (Noah Misch)
     </para>

     <para>
      There are <type>interval</type> values that are distinguishable but
      compare equal, for example <literal>24:00:00</literal>
      and <literal>1 day</literal>.  This breaks assumptions made by btree
      de-duplication, so <type>interval</type> columns need to be excluded
      from de-duplication.  This oversight can cause incorrect results
      from index-only scans.  Moreover, after
      updating <application>amcheck</application> will report an error for
      almost all such indexes.  Users should reindex any btree indexes
      on <type>interval</type> columns.
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [d9e46dfb7] 2023-10-13 01:12:31 +1300
Branch: REL_16_STABLE [595db9e9c] 2023-10-13 01:13:07 +1300
Branch: REL_15_STABLE [1e81d3e6e] 2023-10-13 01:13:36 +1300
Branch: REL_14_STABLE [d26f33c32] 2023-10-13 01:13:59 +1300
Branch: REL_13_STABLE [890a73ba3] 2023-10-13 01:14:22 +1300
Branch: REL_12_STABLE [3cc0c2517] 2023-10-13 01:14:46 +1300
Branch: REL_11_STABLE [2759924f3] 2023-10-13 01:15:12 +1300
Author: David Rowley <drowley@postgresql.org>
Branch: master [f0c409d9c] 2023-10-12 19:50:38 +1300
Branch: REL_16_STABLE [6352f1627] 2023-10-12 19:51:26 +1300
Branch: REL_15_STABLE [916adc7c5] 2023-10-12 19:52:05 +1300
Branch: REL_14_STABLE [cd15bff48] 2023-10-12 19:52:31 +1300
Branch: REL_13_STABLE [45c4b2a3a] 2023-10-12 19:52:58 +1300
Branch: REL_12_STABLE [cd259de50] 2023-10-12 19:53:23 +1300
Branch: REL_11_STABLE [07f261b31] 2023-10-12 19:53:50 +1300
-->
     <para>
      Fix partition step generation and runtime partition pruning for
      hash-partitioned tables with multiple partition keys (David Rowley)
     </para>

     <para>
      Some cases involving an <literal>IS NULL</literal> condition on one
      of the partition keys could result in a crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [714780dcd] 2023-09-28 16:29:37 -0700
Branch: REL_16_STABLE [3fa81b62e] 2023-09-28 16:29:35 -0700
Branch: REL_15_STABLE [cac37c1a1] 2023-09-28 16:29:32 -0700
Branch: REL_14_STABLE [41486c4aa] 2023-09-28 16:29:29 -0700
Branch: REL_13_STABLE [d4724e94a] 2023-09-28 16:29:27 -0700
Branch: REL_12_STABLE [b36d72cbc] 2023-09-28 16:29:24 -0700
Branch: REL_11_STABLE [7c07305e6] 2023-09-28 16:29:22 -0700
-->
     <para>
      Fix edge case in btree mark/restore processing of ScalarArrayOpExpr
      clauses (Peter Geoghegan)
     </para>

     <para>
      When restoring an indexscan to a previously marked position, the
      code could miss required setup steps if the scan had advanced
      exactly to the end of the matches for a ScalarArrayOpExpr (that is,
      an <literal>indexcol = ANY(ARRAY[])</literal>) clause.  This could
      result in missing some rows that should have been fetched.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [237f8765d] 2023-10-28 14:05:01 -0400
Branch: REL_16_STABLE [07494a0df] 2023-10-28 14:04:43 -0400
Branch: REL_15_STABLE [592cb11fb] 2023-10-28 14:04:43 -0400
Branch: REL_14_STABLE [5d7515d7d] 2023-10-28 14:04:43 -0400
Branch: REL_13_STABLE [b7684473d] 2023-10-28 14:04:43 -0400
Branch: REL_12_STABLE [d8d7f282f] 2023-10-28 14:04:43 -0400
Branch: REL_11_STABLE [7ab6971c6] 2023-10-28 14:04:43 -0400
-->
     <para>
      Fix intra-query memory leak when a set-returning function repeatedly
      returns zero rows (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f73fa5a47] 2023-09-18 14:28:17 -0400
Branch: REL_16_STABLE [ec693a3f3] 2023-09-18 14:27:47 -0400
Branch: REL_15_STABLE [95f54f0d0] 2023-09-18 14:27:47 -0400
Branch: REL_14_STABLE [9baabfa38] 2023-09-18 14:27:47 -0400
Branch: REL_13_STABLE [e6e50ada0] 2023-09-18 14:27:47 -0400
Branch: REL_12_STABLE [123337079] 2023-09-18 14:27:47 -0400
Branch: REL_11_STABLE [db00be6d7] 2023-09-18 14:27:47 -0400
-->
     <para>
      Don't crash if <function>cursor_to_xmlschema()</function> is applied
      to a non-data-returning Portal (Boyu Yang)
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [73635b6d6] 2023-10-31 16:42:08 +1300
Branch: REL_16_STABLE [a98f01c93] 2023-10-31 16:42:35 +1300
Branch: REL_15_STABLE [136068353] 2023-10-31 16:43:01 +1300
Branch: REL_14_STABLE [c5988e69f] 2023-10-31 16:43:28 +1300
Branch: REL_13_STABLE [b3c8d1d0e] 2023-10-31 16:44:00 +1300
Branch: REL_12_STABLE [efcb601d2] 2023-10-31 16:44:27 +1300
-->
     <para>
      Throw the intended error if <function>pgrowlocks()</function> is
      applied to a partitioned table (David Rowley)
     </para>

     <para>
      Previously, a not-on-point complaint <quote>only heap AM is
      supported</quote> would be raised.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [13503eb59] 2023-10-30 14:46:05 -0700
Branch: REL_16_STABLE [1a368dd3e] 2023-10-30 14:46:08 -0700
Branch: REL_15_STABLE [e633e9b13] 2023-10-30 14:46:08 -0700
Branch: REL_14_STABLE [0a7b183fd] 2023-10-30 14:46:09 -0700
Branch: REL_13_STABLE [123b0d111] 2023-10-30 14:46:09 -0700
Branch: REL_12_STABLE [975ae0553] 2023-10-30 14:46:09 -0700
Branch: REL_11_STABLE [bae063db4] 2023-10-30 14:46:09 -0700
-->
     <para>
      Handle invalid indexes more cleanly in assorted SQL functions
      (Noah Misch)
     </para>

     <para>
      Report an error if <function>pgstatindex()</function>,
      <function>pgstatginindex()</function>,
      <function>pgstathashindex()</function>,
      or <function>pgstattuple()</function> is applied to an invalid
      index.  If <function>brin_desummarize_range()</function>,
      <function>brin_summarize_new_values()</function>,
      <function>brin_summarize_range()</function>,
      or <function>gin_clean_pending_list()</function> is applied to an
      invalid index, do nothing except to report a debug-level message.
      Formerly these functions attempted to process the index, and might
      fail in strange ways depending on what the failed <command>CREATE
      INDEX</command> had left behind.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [cf1c65070] 2023-09-25 11:50:28 -0400
Branch: REL_16_STABLE [8465efc1a] 2023-09-25 11:50:28 -0400
Branch: REL_15_STABLE [71bb73f60] 2023-09-25 11:50:28 -0400
Branch: REL_14_STABLE [a2799f53d] 2023-09-25 11:50:28 -0400
Branch: REL_13_STABLE [52a676ef4] 2023-09-25 11:50:28 -0400
Branch: REL_12_STABLE [4a81ed29d] 2023-09-25 11:50:28 -0400
Branch: REL_11_STABLE [0fb91ed2b] 2023-09-25 11:50:28 -0400
-->
     <para>
      Avoid premature memory allocation failure with long inputs
      to <function>to_tsvector()</function> (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5b7b38246] 2023-10-01 13:16:47 -0400
Branch: REL_16_STABLE [5c34a7374] 2023-10-01 13:16:59 -0400
Branch: REL_15_STABLE [55e188a15] 2023-10-01 13:17:06 -0400
Branch: REL_14_STABLE [cf12c4fd2] 2023-10-01 13:17:11 -0400
Branch: REL_13_STABLE [9da153846] 2023-10-01 13:17:15 -0400
Branch: REL_12_STABLE [2296bc362] 2023-10-01 13:17:20 -0400
Branch: REL_11_STABLE [7a310cae0] 2023-10-01 13:17:25 -0400
-->
     <para>
      Fix over-allocation of the constructed <type>tsvector</type>
      in <function>tsvectorrecv()</function> (Denis Erokhin)
     </para>

     <para>
      If the incoming vector includes position data, the binary receive
      function left wasted space (roughly equal to the size of the
      position data) in the finished <type>tsvector</type>.  In extreme
      cases this could lead to <quote>maximum total lexeme length
      exceeded</quote> failures for vectors that were under the length
      limit when emitted.  In any case it could lead to wasted space
      on-disk.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [ae10dbb0c] 2023-09-04 14:55:37 +0900
Branch: REL_16_STABLE Release: REL_16_0 [fac3fa0d5] 2023-09-04 14:55:49 +0900
Branch: REL_15_STABLE [88aa4a049] 2023-09-04 14:55:51 +0900
Branch: REL_14_STABLE [df11421d8] 2023-09-04 14:55:53 +0900
Branch: REL_13_STABLE [82fa8ae5f] 2023-09-04 14:55:55 +0900
Branch: REL_12_STABLE [40ddb8db9] 2023-09-04 14:55:57 +0900
Branch: REL_11_STABLE [358cd2b25] 2023-09-04 14:55:58 +0900
-->
     <para>
      Fix incorrect coding in <function>gtsvector_picksplit()</function>
      (Alexander Lakhin)
     </para>

     <para>
      This could lead to poor page-split decisions in GiST indexes
      on <type>tsvector</type> columns.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9b103f861] 2023-10-18 20:43:27 -0400
Branch: REL_16_STABLE [cfa4eba02] 2023-10-18 20:43:17 -0400
Branch: REL_15_STABLE [985ac5ce2] 2023-10-18 20:43:17 -0400
Branch: REL_14_STABLE [2c63dc035] 2023-10-18 20:43:17 -0400
Branch: REL_13_STABLE [817669ea2] 2023-10-18 20:43:17 -0400
-->
     <para>
      Improve checks for corrupt PGLZ compressed data (Flavien Guedez)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [48e2b234f] 2023-09-21 23:11:30 -0400
Branch: REL_16_STABLE [227c7cf15] 2023-09-21 23:11:30 -0400 !! no live bug
Branch: REL_15_STABLE [77dc81602] 2023-09-21 23:11:31 -0400 !! no live bug
Branch: REL_14_STABLE [10323f140] 2023-09-21 23:11:31 -0400
Branch: REL_13_STABLE [555a8d9d3] 2023-09-21 23:11:31 -0400
Branch: REL_12_STABLE [7cabb20a9] 2023-09-21 23:11:31 -0400
-->
     <para>
      Fix <command>COMMIT AND CHAIN</command>/<command>ROLLBACK AND
      CHAIN</command> to work properly when there is an unreleased
      savepoint (Liu Xiang, Tom Lane)
     </para>

     <para>
      Instead of propagating the current transaction's properties to the
      new transaction, they propagated some previous transaction's
      properties.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7704a1a72] 2023-11-02 11:47:33 -0400
Branch: REL_16_STABLE [82063edd4] 2023-11-02 11:47:33 -0400
Branch: REL_15_STABLE [ae33659d4] 2023-11-02 11:47:33 -0400
Branch: REL_14_STABLE [47c0f00cf] 2023-11-02 11:47:33 -0400
Branch: REL_13_STABLE [137227c6d] 2023-11-02 11:47:33 -0400
Branch: REL_12_STABLE [65810fc6d] 2023-11-02 11:47:33 -0400
Branch: REL_11_STABLE [6e1cca511] 2023-11-02 11:47:33 -0400 !! no live bug
-->
     <para>
      Avoid crash in <command>EXPLAIN</command> if a parameter marked to
      be displayed by <command>EXPLAIN</command> has a NULL boot-time
      value (Xing Guo, Aleksander Alekseev, Tom Lane)
     </para>

     <para>
      No built-in parameter fits this description, but an extension could
      define such a parameter.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [54b208f90] 2023-10-16 14:06:14 -0400
Branch: REL_16_STABLE [57e6e861d] 2023-10-16 14:06:15 -0400
Branch: REL_15_STABLE [0d1a7cd14] 2023-10-16 14:06:15 -0400
Branch: REL_14_STABLE [f6e1ee3cf] 2023-10-16 14:06:11 -0400
Branch: REL_13_STABLE [1e678175c] 2023-10-16 14:06:11 -0400
Branch: REL_12_STABLE [07eb22a77] 2023-10-16 14:06:11 -0400
Branch: REL_11_STABLE [a295684b8] 2023-10-16 14:06:12 -0400
-->
     <para>
      Ensure we have a snapshot while dropping <literal>ON COMMIT
      DROP</literal> temp tables (Tom Lane)
     </para>

     <para>
      This prevents possible misbehavior if any catalog entries for the
      temp tables have fields wide enough to require toasting (such as a
      very complex <literal>CHECK</literal> condition).
     </para>
    </listitem>

    <listitem>
<!--
Author: Nathan Bossart <nathan@postgresql.org>
Branch: master [97550c071] 2023-10-17 10:41:48 -0500
Branch: REL_16_STABLE [ee06199fc] 2023-10-17 10:41:58 -0500
Branch: REL_15_STABLE [c9265ae80] 2023-10-17 10:42:06 -0500
Branch: REL_14_STABLE [54fc9dca5] 2023-10-17 10:42:12 -0500
Branch: REL_13_STABLE [ac1dfc303] 2023-10-17 10:42:17 -0500
Branch: REL_12_STABLE [e2e169042] 2023-10-17 10:42:22 -0500
Branch: REL_11_STABLE [d0e7f95b4] 2023-10-17 10:42:28 -0500
Author: Nathan Bossart <nathan@postgresql.org>
Branch: REL_14_STABLE [555bc89c9] 2023-10-17 16:11:03 -0500
Branch: REL_13_STABLE [ebc093fa6] 2023-10-17 16:11:08 -0500
Branch: REL_12_STABLE [0e32652a7] 2023-10-17 16:11:13 -0500
Branch: REL_11_STABLE [bc322c73c] 2023-10-17 16:11:18 -0500
-->
     <para>
      Avoid improper response to shutdown signals in child processes
      just forked by <function>system()</function> (Nathan Bossart)
     </para>

     <para>
      This fix avoids a race condition in which a child process that has
      been forked off by <function>system()</function>, but hasn't yet
      exec'd the intended child program, might receive and act on a signal
      intended for the parent server process.  That would lead to
      duplicate cleanup actions being performed, which will not end well.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [63a582222] 2023-10-16 17:33:08 +1300
Branch: REL_16_STABLE [5725e4ebe] 2023-10-16 17:21:41 +1300
Branch: REL_15_STABLE [5e39884d3] 2023-10-16 17:23:02 +1300
Branch: REL_14_STABLE [dc75748a9] 2023-10-16 17:23:25 +1300
Branch: REL_13_STABLE [67060be3d] 2023-10-16 17:24:35 +1300
Branch: REL_12_STABLE [43c979086] 2023-10-16 17:25:43 +1300
-->
     <para>
      Cope with torn reads of <filename>pg_control</filename> in frontend
      programs (Thomas Munro)
     </para>

     <para>
      On some file systems, reading <filename>pg_control</filename> may
      not be an atomic action when the server concurrently writes that
      file.  This is detectable via a bad CRC.  Retry a few times to see
      if the file becomes valid before we report error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [c558e6fd9] 2023-10-16 10:43:47 +1300
Branch: REL_16_STABLE [2371432cd] 2023-10-16 10:45:05 +1300
Branch: REL_15_STABLE [606be8a35] 2023-10-16 10:45:18 +1300
Branch: REL_14_STABLE [a56fe5cf0] 2023-10-16 10:47:01 +1300
Branch: REL_13_STABLE [ae9da357b] 2023-10-16 10:47:10 +1300
Branch: REL_12_STABLE [637e86ecc] 2023-10-16 10:47:33 +1300
Branch: REL_11_STABLE [f1634c968] 2023-10-16 10:52:40 +1300
-->
     <para>
      Avoid torn reads of <filename>pg_control</filename> in relevant SQL
      functions (Thomas Munro)
     </para>

     <para>
      Acquire the appropriate lock before
      reading <filename>pg_control</filename>, to ensure we get a
      consistent view of that file.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [a956bd3fa] 2023-10-03 15:37:00 +0900
Branch: REL_16_STABLE [75f31a3f2] 2023-10-03 15:37:18 +0900
Branch: REL_15_STABLE [95e91da66] 2023-10-03 15:37:19 +0900
Branch: REL_14_STABLE [f91c87b31] 2023-10-03 15:37:21 +0900
Branch: REL_13_STABLE [a0b013625] 2023-10-03 15:37:23 +0900
Branch: REL_12_STABLE [9b3900cdb] 2023-10-03 15:37:24 +0900
-->
     <para>
      Avoid integer overflow when computing size of backend activity
      string array (Jakub Wartak)
     </para>

     <para>
      On 64-bit machines we will allow values
      of <varname>track_activity_query_size</varname> large enough to
      cause 32-bit overflow when multiplied by the allowed number of
      connections.  The code actually allocating the per-backend local
      array was careless about this though, and allocated the array
      incorrectly.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [c181f2e2b] 2023-09-30 17:03:50 +0300
Branch: REL_16_STABLE [992d2ca81] 2023-09-30 17:07:24 +0300
Branch: REL_15_STABLE [5ae245664] 2023-09-30 17:07:32 +0300
Branch: REL_14_STABLE [2d4f99bc6] 2023-09-30 17:07:37 +0300
Branch: REL_13_STABLE [ed9247cd7] 2023-09-30 17:07:41 +0300
-->
     <para>
      Fix briefly showing inconsistent progress statistics
      for <command>ANALYZE</command> on inherited tables
      (Heikki Linnakangas)
     </para>

     <para>
      The block-level counters should be reset to zero at the same time we
      update the current-relation field.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [dc8d72c1c] 2023-09-25 14:42:17 -0400
Branch: REL_16_STABLE [055f786ea] 2023-09-25 14:42:17 -0400
Branch: REL_15_STABLE [0e59266a5] 2023-09-25 14:41:57 -0400
Branch: REL_14_STABLE [5cff431bc] 2023-09-25 14:41:57 -0400
Branch: REL_13_STABLE [8cfc3e80b] 2023-09-25 14:41:57 -0400
Branch: REL_12_STABLE [4435a8d5d] 2023-09-25 14:41:57 -0400
Branch: REL_11_STABLE [fdc7cf73b] 2023-09-25 14:41:57 -0400
-->
     <para>
      Track the dependencies of cached <command>CALL</command> statements,
      and re-plan them when needed (Tom Lane)
     </para>

     <para>
      DDL commands, such as replacement of a function that has been
      inlined into a <command>CALL</command> argument, can create the need
      to re-plan a <command>CALL</command> that has been cached by
      PL/pgSQL.  That was not happening, leading to misbehavior or strange
      errors such as <quote>cache lookup failed</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e0e492e5a] 2023-09-15 17:01:52 -0400
Branch: REL_16_STABLE [53630f12d] 2023-09-15 17:01:26 -0400
Branch: REL_15_STABLE [2679a107a] 2023-09-15 17:01:26 -0400
Branch: REL_14_STABLE [ae13f8166] 2023-09-15 17:01:26 -0400
Branch: REL_13_STABLE [c5b7f791d] 2023-09-15 17:01:26 -0400
Branch: REL_12_STABLE [d29812c0c] 2023-09-15 17:01:26 -0400
Branch: REL_11_STABLE [a374f6c61] 2023-09-15 17:01:26 -0400
-->
     <para>
      Track nesting depth correctly when
      inspecting <type>RECORD</type>-type Vars from outer query levels
      (Richard Guo)
     </para>

     <para>
      This oversight could lead to assertion failures, core dumps,
      or <quote>bogus varno</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_13_STABLE [59bc0dfe4] 2023-09-15 16:39:27 -0400
Branch: REL_12_STABLE [8a15b4178] 2023-09-15 16:39:27 -0400
Branch: REL_11_STABLE [479b99125] 2023-09-15 16:39:27 -0400
-->
     <para>
      Avoid <quote>record type has not been registered</quote> failure
      when deparsing a view that contains references to fields of
      composite constants (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [3acd0599b] 2023-09-13 14:58:22 +1200
Branch: REL_16_STABLE [f899c7f1e] 2023-09-13 15:06:07 +1200
Branch: REL_15_STABLE [a26cc0334] 2023-09-13 14:43:04 +1200
Branch: REL_14_STABLE [e2452c2a6] 2023-09-13 14:46:16 +1200
Branch: REL_13_STABLE [189097db8] 2023-09-13 14:48:00 +1200
Branch: REL_12_STABLE [012b80ad2] 2023-09-13 14:50:14 +1200
Branch: REL_11_STABLE [6ae57f190] 2023-09-13 14:52:34 +1200
-->
     <para>
      Fix error-handling bug in <type>RECORD</type> type cache management
      (Thomas Munro)
     </para>

     <para>
      An out-of-memory error occurring at just the wrong point could leave
      behind inconsistent state that would lead to an infinite loop.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: REL_15_STABLE [c7256e656] 2023-09-12 10:23:17 +0530
Branch: REL_14_STABLE [f7d25117b] 2023-09-12 10:12:51 +0530
Branch: REL_13_STABLE [c570bb4d6] 2023-09-12 09:58:50 +0530
Branch: REL_12_STABLE [7e57208ed] 2023-09-12 09:44:37 +0530
Branch: REL_11_STABLE [feb4e218e] 2023-09-12 09:36:56 +0530
-->
     <para>
      Fix assertion failure when logical decoding is retried in the same
      session after an error (Hou Zhijie)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [6b18b3fe2] 2023-10-03 10:21:44 +0900
Branch: REL_16_STABLE [a06efbc3a] 2023-10-03 10:25:12 +0900
Branch: REL_15_STABLE [afc79591d] 2023-10-03 10:25:14 +0900
Branch: REL_14_STABLE [baeb8542c] 2023-10-03 10:25:15 +0900
Branch: REL_13_STABLE [6103d2cca] 2023-10-03 10:25:17 +0900
Branch: REL_12_STABLE [22b2e6e9d] 2023-10-03 10:25:19 +0900
-->
     <para>
      Treat out-of-memory failures as fatal while reading WAL
      (Michael Paquier)
     </para>

     <para>
      Previously this would be treated as a bogus-data condition, leading
      to the conclusion that we'd reached the end of WAL, which is
      incorrect and could lead to inconsistent WAL replay.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [bae868caf] 2023-09-23 10:26:24 +1200
Branch: REL_16_STABLE [ce497f648] 2023-09-23 10:27:02 +1200
Branch: REL_15_STABLE [f4d152edd] 2023-09-23 10:28:12 +1200
Branch: REL_14_STABLE [3ce3b53d7] 2023-09-23 10:28:40 +1200
Branch: REL_13_STABLE [6606c5716] 2023-09-23 10:29:44 +1200
Branch: REL_12_STABLE [e8f3c0687] 2023-09-23 10:29:56 +1200
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [becfbdd6c] 2023-09-26 10:53:38 +1300
Branch: REL_16_STABLE [10d0591ea] 2023-09-26 10:53:52 +1300
Branch: REL_15_STABLE [99d334a18] 2023-09-26 10:54:02 +1300
Branch: REL_14_STABLE [3d413c5a7] 2023-09-26 10:54:24 +1300
Branch: REL_13_STABLE [45d1fe8b5] 2023-09-26 10:54:47 +1300
Branch: REL_12_STABLE [bde2f1847] 2023-09-26 10:59:49 +1300
-->
     <para>
      Fix possible recovery failure due to trying to allocate memory based
      on a bogus WAL record length field (Thomas Munro, Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: REL_14_STABLE [2f13e8d9e] 2023-09-12 09:35:42 +0900
Branch: REL_13_STABLE [5dc093eac] 2023-09-12 09:35:51 +0900
Branch: REL_12_STABLE [7b03d3a3b] 2023-09-12 09:35:57 +0900
-->
     <para>
      Ensure that standby-mode WAL recovery reports an error when an
      invalid page header is found (Yugo Nagata, Kyotaro Horiguchi)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [52c6c0f19] 2023-08-30 08:03:42 +0900
Branch: REL_16_STABLE Release: REL_16_0 [1d2939b6d] 2023-08-30 08:03:48 +0900
Branch: REL_15_STABLE [5180160c1] 2023-08-30 08:03:51 +0900
Branch: REL_14_STABLE [d2bd4ba30] 2023-08-30 08:03:52 +0900
Branch: REL_13_STABLE [420c8dc7e] 2023-08-30 08:03:54 +0900
-->
     <para>
      Fix datatype size confusion in logical tape management
      (Ranier Vilela)
     </para>

     <para>
      Integer overflow was possible on platforms where long is wider than
      int, although it would take a multiple-terabyte temporary file to
      cause a problem.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [5fec3c870] 2023-08-29 09:09:40 +0300
Branch: REL_16_STABLE Release: REL_16_0 [5f38ff3d0] 2023-08-29 09:10:28 +0300
Branch: REL_15_STABLE [0c1024060] 2023-08-29 09:12:35 +0300
Branch: REL_14_STABLE [3d895f95a] 2023-08-29 09:12:24 +0300
Branch: REL_13_STABLE [a01e479e8] 2023-08-29 09:12:17 +0300
-->
     <para>
      Avoid unintended close of syslogger process's stdin
      (Heikki Linnakangas)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d8b2fcc9d] 2023-08-24 12:02:46 -0400
Branch: REL_16_STABLE Release: REL_16_0 [ba0d737ca] 2023-08-24 12:02:40 -0400
Branch: REL_15_STABLE [870085135] 2023-08-24 12:02:40 -0400
Branch: REL_14_STABLE [9b2a41db1] 2023-08-24 12:02:40 -0400
Branch: REL_13_STABLE [27566bcf3] 2023-08-24 12:02:40 -0400
Branch: REL_12_STABLE [b808dbf90] 2023-08-24 12:02:40 -0400
Branch: REL_11_STABLE [9c59f3862] 2023-08-24 12:02:40 -0400
-->
     <para>
      Avoid doing plan cache revalidation of utility statements
      that do not receive interesting processing during parse analysis
      (Tom Lane)
     </para>

     <para>
      Aside from saving a few cycles, this prevents failure after a cache
      invalidation for statements that must not set a snapshot, such
      as <command>SET TRANSACTION ISOLATION LEVEL</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [a68458108] 2023-08-22 15:17:05 -0400
Branch: REL_16_STABLE Release: REL_16_0 [f938acd68] 2023-08-22 15:18:19 -0400
Branch: REL_15_STABLE [75f323aa1] 2023-08-22 15:16:01 -0400
Branch: REL_14_STABLE [7f4515a58] 2023-08-22 15:15:45 -0400
Branch: REL_13_STABLE [1bb619d4d] 2023-08-22 15:15:31 -0400
Branch: REL_12_STABLE [01993ac74] 2023-08-22 15:15:18 -0400
Branch: REL_11_STABLE [2d13dab04] 2023-08-23 17:22:16 -0400
Branch: REL_11_STABLE [b915bf495] 2023-08-24 16:14:26 -0400
-->
     <para>
      Keep by-reference <structfield>attmissingval</structfield> values in
      a long-lived context while they are being used (Andrew Dunstan)
     </para>

     <para>
      This avoids possible use of dangling pointers when a tuple slot
      outlives the tuple descriptor with which its value was constructed.
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [fa2e87494] 2023-08-09 13:09:25 -0700
Branch: REL_16_STABLE Release: REL_16_0 [0d56c32c8] 2023-08-09 13:09:01 -0700
Branch: REL_15_STABLE [9f3343e40] 2023-08-07 15:12:49 -0700
Branch: REL_14_STABLE [00953f1e2] 2023-08-07 15:12:33 -0700
Branch: REL_13_STABLE [90cadfd49] 2023-08-07 15:12:09 -0700
Branch: REL_12_STABLE [a86d40227] 2023-08-07 15:11:18 -0700
Branch: REL_11_STABLE [43ba5105a] 2023-08-07 15:09:11 -0700
Branch: master [bee263b08] 2023-08-10 10:20:54 -0700
Branch: REL_16_STABLE Release: REL_16_0 [7bed93a46] 2023-08-10 10:24:58 -0700
Branch: REL_15_STABLE [1bc19dfcf] 2023-08-10 10:25:47 -0700
Branch: REL_14_STABLE [5a32af3f2] 2023-08-10 10:26:12 -0700
Branch: REL_13_STABLE [4caa9e33e] 2023-08-10 10:26:46 -0700
Branch: REL_12_STABLE [01bc42634] 2023-08-10 10:27:00 -0700
Branch: REL_11_STABLE [ae1269295] 2023-08-10 10:27:24 -0700
-->
     <para>
      Recalculate the effective value of <varname>search_path</varname>
      after <command>ALTER ROLE</command> (Jeff Davis)
     </para>

     <para>
      This ensures that after renaming a role, the meaning of the special
      string <literal>$user</literal> is re-determined.
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [ef74c7197] 2023-10-10 11:01:13 -0700
Branch: REL_16_STABLE [b8963e8a2] 2023-10-10 11:01:55 -0700
Branch: REL_15_STABLE [b9bb02620] 2023-10-10 11:02:45 -0700
Branch: REL_14_STABLE [6615bb95a] 2023-10-10 11:02:56 -0700
Branch: REL_13_STABLE [469d367be] 2023-10-10 11:03:03 -0700
Branch: REL_12_STABLE [6dbd01b9f] 2023-10-10 11:03:10 -0700
Branch: REL_11_STABLE [04f0baa85] 2023-10-10 11:03:20 -0700
-->
     <para>
      Fix order of operations in <function>GenericXLogFinish</function>
      (Jeff Davis)
     </para>

     <para>
      This code violated the conditions required for crash safety by
      writing WAL before marking changed buffers dirty.  No core code uses
      this function, but extensions do (<filename>contrib/bloom</filename>
      does, for example).
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [af5b3c3d1] 2023-09-19 08:31:06 +0900
Branch: REL_16_STABLE [f171430f0] 2023-09-19 08:31:22 +0900
Branch: REL_15_STABLE [9e0ce80f3] 2023-09-19 08:31:24 +0900
Branch: REL_14_STABLE [bb65f3c1b] 2023-09-19 08:31:26 +0900
Branch: REL_13_STABLE [35e8ba3e5] 2023-09-19 08:31:27 +0900
Branch: REL_12_STABLE [99d27e55c] 2023-09-19 08:31:29 +0900
Branch: REL_11_STABLE [ddded779a] 2023-09-19 08:31:31 +0900
-->
     <para>
      Remove incorrect assertion in PL/Python exception handling
      (Alexander Lakhin)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [06c0c3688] 2023-10-02 13:27:58 -0400
Branch: REL_16_STABLE [aaaf8fbb6] 2023-10-02 13:27:51 -0400
Branch: REL_15_STABLE [10e705bd2] 2023-10-02 13:27:51 -0400
Branch: REL_14_STABLE [829d91cc6] 2023-10-02 13:27:51 -0400
Branch: REL_13_STABLE [295953f8b] 2023-10-02 13:27:51 -0400
Branch: REL_12_STABLE [c02f29758] 2023-10-02 13:27:51 -0400
Branch: REL_11_STABLE [4f16152d9] 2023-10-02 13:27:51 -0400
-->
     <para>
      Fix <application>pg_restore</application> so that selective restores
      will include both table-level and column-level ACLs for selected
      tables (Euler Taveira, Tom Lane)
     </para>

     <para>
      Formerly, only the table-level ACL would get restored if both types
      were present.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [2e3dc8c14] 2023-09-25 14:27:33 +0200
Branch: REL_16_STABLE [fb9ddd0fa] 2023-09-25 14:34:06 +0200
Branch: REL_15_STABLE [8845d8597] 2023-09-25 14:34:06 +0200
Branch: REL_14_STABLE [26c291a15] 2023-09-25 14:34:06 +0200
Branch: REL_13_STABLE [d3946c4f6] 2023-09-25 14:34:05 +0200
Branch: REL_12_STABLE [af9f6cd1d] 2023-09-25 14:34:05 +0200
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: REL_15_STABLE [04d2d605f] 2023-11-03 12:07:11 -0400
Branch: REL_14_STABLE [f9280e77e] 2023-11-03 12:07:25 -0400
Branch: REL_13_STABLE [2f1f49975] 2023-11-03 12:07:35 -0400
Branch: REL_12_STABLE [d3246a2ad] 2023-11-03 12:07:40 -0400
-->
     <para>
      Add logic to <application>pg_upgrade</application> to check for use
      of <type>abstime</type>, <type>reltime</type>,
      and <type>tinterval</type> data types (&Aacute;lvaro Herrera)
     </para>

     <para>
      These obsolete data types were removed
      in <productname>PostgreSQL</productname> version 12, so check to
      make sure they aren't present in an older database before claiming
      it can be upgraded.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [e1c6db630] 2023-09-07 14:12:18 +0900
Branch: REL_16_STABLE Release: REL_16_0 [105795843] 2023-09-07 14:12:25 +0900
Branch: REL_15_STABLE [574bff7bd] 2023-09-07 14:12:29 +0900
Branch: REL_14_STABLE [9de74ca70] 2023-09-07 14:12:31 +0900
Branch: REL_13_STABLE [6cdd7b805] 2023-09-07 14:12:33 +0900
Branch: REL_12_STABLE [2fe968ce9] 2023-09-07 14:12:34 +0900
Branch: REL_11_STABLE [dbd1a06c9] 2023-09-07 14:12:36 +0900
-->
     <para>
      Avoid generating invalid temporary slot names
      in <application>pg_basebackup</application> (Jelte Fennema)
     </para>

     <para>
      This has only been seen to occur when the server connection runs
      through <application>pgbouncer</application>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [90ebcc32d] 2023-10-14 15:54:46 -0700
Branch: REL_16_STABLE [06ff06484] 2023-10-14 15:54:49 -0700
Branch: REL_15_STABLE [1102f4ece] 2023-10-14 15:54:49 -0700
Branch: REL_14_STABLE [0df88a686] 2023-10-14 15:54:49 -0700
Branch: REL_13_STABLE [3895e9153] 2023-10-14 15:54:50 -0700
Branch: REL_12_STABLE [73cda80a3] 2023-10-14 15:54:50 -0700
-->
     <para>
      Avoid false <quote>too many client connections</quote> errors
      in <application>pgbench</application> on Windows (Noah Misch)
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [6ec9e9975] 2023-10-30 14:46:05 -0700
Branch: REL_16_STABLE [3c6a05b80] 2023-10-30 14:46:08 -0700
Branch: REL_15_STABLE [6f81386a9] 2023-10-30 14:46:08 -0700
Branch: REL_14_STABLE [42496cba6] 2023-10-30 14:46:09 -0700
Branch: REL_13_STABLE [f31ccb575] 2023-10-30 14:46:09 -0700
Branch: REL_12_STABLE [3a205c916] 2023-10-30 14:46:09 -0700
Branch: REL_11_STABLE [e04509f32] 2023-10-30 14:46:09 -0700
-->
     <para>
      In <filename>contrib/amcheck</filename>, do not report interrupted
      page deletion as corruption (Noah Misch)
     </para>

     <para>
      This fix prevents false-positive reports of <quote>the first child
      of leftmost target page is not leftmost of its
      level</quote>, <quote>block NNNN is not leftmost</quote>
      or <quote>left link/right link pair in index XXXX not in
      agreement</quote>.  They appeared
      if <application>amcheck</application> ran after an unfinished btree
      index page deletion and before <command>VACUUM</command> had cleaned
      things up.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [849172ff4] 2023-10-29 11:14:37 +0000
Branch: REL_16_STABLE [ab73a37e9] 2023-10-29 11:14:36 +0000
Branch: REL_15_STABLE [5f0691839] 2023-10-29 11:14:35 +0000
Branch: REL_14_STABLE [162b38a06] 2023-10-29 11:14:34 +0000
Branch: REL_13_STABLE [35e6a5c20] 2023-10-29 11:14:34 +0000
Branch: REL_12_STABLE [f7cd7b265] 2023-10-29 11:14:33 +0000
Branch: REL_11_STABLE [c804ffb56] 2023-10-29 11:14:32 +0000
-->
     <para>
      Fix failure of <filename>contrib/btree_gin</filename> indexes
      on <type>interval</type> columns,
      when an indexscan using the <literal>&lt;</literal>
      or <literal>&lt;=</literal> operator is performed (Dean Rasheed)
     </para>

     <para>
      Such an indexscan failed to return all the entries it should.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [76200e5ee] 2023-10-19 05:13:23 +1300
Branch: REL_16_STABLE [774185056] 2023-10-19 05:14:07 +1300
Branch: REL_15_STABLE [b60e3ac76] 2023-10-19 05:15:38 +1300
Branch: REL_14_STABLE [0a8b7d5c1] 2023-10-19 05:16:00 +1300
Branch: REL_13_STABLE [53c4dabe1] 2023-10-19 05:16:24 +1300
Branch: REL_12_STABLE [7da915e33] 2023-10-19 05:17:27 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [37d5babb5] 2023-10-18 22:47:23 +1300
Branch: REL_16_STABLE [74d19ec09] 2023-10-18 22:53:56 +1300
Branch: REL_15_STABLE [eed1feb3f] 2023-10-18 22:59:46 +1300
Branch: REL_14_STABLE [82d9a782a] 2023-10-18 23:04:09 +1300
Branch: REL_13_STABLE [f28956b23] 2023-10-18 23:16:48 +1300
Branch: REL_12_STABLE [15ddc9725] 2023-10-18 23:18:16 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [f90b4a846] 2023-10-19 03:01:55 +1300
Branch: REL_16_STABLE [60596f148] 2023-10-19 03:07:18 +1300
Branch: REL_15_STABLE [b2e097788] 2023-10-19 03:03:27 +1300
Branch: REL_14_STABLE [ee3e4c41f] 2023-10-19 03:03:46 +1300
Branch: REL_13_STABLE [981292c19] 2023-10-19 03:04:00 +1300
Branch: REL_12_STABLE [d701f0d1f] 2023-10-19 03:04:09 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: REL_13_STABLE [7c070e224] 2023-10-24 11:23:08 +1300
Branch: REL_12_STABLE [9ad986276] 2023-10-24 11:23:21 +1300
-->
     <para>
      Add support for LLVM 16 and 17 (Thomas Munro, Dmitry Dolgov)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [06843df4a] 2023-09-29 14:07:30 -0400
Branch: REL_16_STABLE [75c562653] 2023-09-29 14:07:30 -0400
Branch: REL_15_STABLE [be3398ea1] 2023-09-29 14:07:30 -0400
Branch: REL_14_STABLE [e9d1560d3] 2023-09-29 14:07:30 -0400
Branch: REL_13_STABLE [1b64e374c] 2023-09-29 14:07:30 -0400
Branch: REL_12_STABLE [d8ceb98e4] 2023-09-29 14:07:30 -0400
Branch: REL_11_STABLE [4d10fda52] 2023-09-29 14:07:30 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3aa021b29] 2023-09-26 21:06:21 -0400
Branch: REL_16_STABLE [e73d6a0df] 2023-09-26 21:06:21 -0400
Branch: REL_15_STABLE [78f17fb97] 2023-09-26 21:06:21 -0400
Branch: REL_14_STABLE [5d60e8ed3] 2023-09-26 21:06:21 -0400
Branch: REL_13_STABLE [53cc19bfa] 2023-09-26 21:06:21 -0400
Branch: REL_12_STABLE [abe423712] 2023-09-26 21:06:21 -0400
Branch: REL_11_STABLE [0e0de20c8] 2023-09-26 21:06:21 -0400
-->
     <para>
      Suppress assorted build-time warnings on
      recent <productname>macOS</productname> (Tom Lane)
     </para>

     <para>
      <productname>Xcode 15</productname> (released
      with <productname>macOS Sonoma</productname>) changed the linker's
      behavior in a way that causes many duplicate-library warnings while
      building <productname>PostgreSQL</productname>.  These were
      harmless, but they're annoying so avoid citing the same libraries
      twice.  Also remove use of the <option>-multiply_defined
      suppress</option> linker switch, which apparently has been a no-op
      for a long time, and is now actively complained of.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [6fc3a138b] 2023-09-27 14:40:23 +0900
Branch: REL_16_STABLE [641db601b] 2023-09-27 14:41:15 +0900
Branch: REL_15_STABLE [8a9e4e84e] 2023-09-27 14:41:21 +0900
Branch: REL_14_STABLE [e4d7ad30f] 2023-09-27 14:41:23 +0900
Branch: REL_13_STABLE [a64b8b035] 2023-09-27 14:41:26 +0900
-->
     <para>
      When building <filename>contrib/unaccent</filename>'s rules file,
      fall back to using <literal>python</literal>
      if <literal>--with-python</literal> was not given and make
      variable <literal>PYTHON</literal> was not set (Japin Li)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5fd3e06f6] 2023-10-28 11:54:40 -0400
Branch: REL_16_STABLE [d1537afe3] 2023-10-28 11:54:51 -0400
Branch: REL_15_STABLE [85b98a70b] 2023-10-28 11:54:59 -0400
Branch: REL_14_STABLE [877e7b4b9] 2023-10-28 11:55:06 -0400
Branch: REL_13_STABLE [d94612873] 2023-10-28 11:55:14 -0400
Branch: REL_12_STABLE [7180bb827] 2023-10-28 11:55:22 -0400
Branch: REL_11_STABLE [64fc5e005] 2023-10-28 11:55:30 -0400
-->
     <para>
      Remove <literal>PHOT</literal> (Phoenix Islands Time) from the
      default timezone abbreviations list (Tom Lane)
     </para>

     <para>
      Presence of this abbreviation in the default list can cause failures
      on recent Debian and Ubuntu releases, as they no longer install the
      underlying tzdb entry by default.  Since this is a made-up
      abbreviation for a zone with a total human population of about two
      dozen, it seems unlikely that anyone will miss it.  If someone does,
      they can put it back via a custom abbreviations file.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-12">
  <title>Release 13.12</title>

  <formalpara>
  <title>Release date:</title>
  <para>2023-08-10</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.11.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.12</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you use BRIN indexes, it may be advisable to reindex them;
    see the second changelog entry below.
   </para>

   <para>
    Also, if you are upgrading from a version earlier than 13.7,
    see <xref linkend="release-13-7"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [cd5f2a357] 2023-08-07 06:05:56 -0700
Branch: REL_16_STABLE [f53511010] 2023-08-07 06:05:59 -0700
Branch: REL_15_STABLE [de494ec14] 2023-08-07 06:06:00 -0700
Branch: REL_14_STABLE [d4648a74b] 2023-08-07 06:06:00 -0700
Branch: REL_13_STABLE [b1b585e0f] 2023-08-07 06:06:00 -0700
Branch: REL_12_STABLE [eb044d8f0] 2023-08-07 06:06:00 -0700
Branch: REL_11_STABLE [919ebb023] 2023-08-07 06:06:01 -0700
-->
     <para>
      Disallow substituting a schema or owner name into an extension script
      if the name contains a quote, backslash, or dollar sign (Noah Misch)
     </para>

     <para>
      This restriction guards against SQL-injection hazards for trusted
      extensions.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks Micah Gates,
      Valerie Woolard, Tim Carey-Smith, and Christoph Berg for reporting
      this problem.
      (CVE-2023-39417)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master Release: REL_16_BR [3581cbdcd] 2023-05-19 01:29:44 +0200
Branch: REL_15_STABLE [e18769323] 2023-05-19 00:15:13 +0200
Branch: REL_14_STABLE [40d465caf] 2023-05-19 00:15:00 +0200
Branch: REL_13_STABLE [6c512fc6e] 2023-05-19 00:14:05 +0200
Branch: REL_12_STABLE [d78a66d92] 2023-05-19 00:16:13 +0200
Branch: REL_11_STABLE [fc7dc728d] 2023-05-19 00:21:05 +0200
Branch: master Release: REL_16_BR [3ec8a3bfb] 2023-05-18 23:33:23 +0200
Branch: REL_15_STABLE [80f64b900] 2023-05-18 23:33:45 +0200
Branch: REL_14_STABLE [3f1356e5d] 2023-05-18 23:34:10 +0200
Branch: REL_13_STABLE [2b1ab28b9] 2023-05-18 23:34:35 +0200
Branch: REL_12_STABLE [d42ffda68] 2023-05-18 23:34:56 +0200
Branch: REL_11_STABLE [b511d7323] 2023-05-18 23:35:16 +0200
-->
     <para>
      Fix confusion between empty (no rows) ranges and all-NULL ranges in
      BRIN indexes, as well as incorrect merging of all-NULL summaries
      (Tomas Vondra)
     </para>

     <para>
      Each of these oversights could result in forgetting that a BRIN
      index range contains any NULL values, potentially allowing
      subsequent queries that should return NULL values to miss doing so.
     </para>

     <para>
      This fix will not in itself correct faulty BRIN entries.
      It's recommended to <command>REINDEX</command> any BRIN indexes that
      may be used to search for nulls.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [c66a7d75e] 2023-07-13 13:03:28 -0700
Branch: REL_16_STABLE [a4b4cc1d6] 2023-07-13 13:03:30 -0700
Branch: REL_15_STABLE [f66403749] 2023-07-13 13:04:45 -0700
Branch: REL_14_STABLE [d11efe830] 2023-07-13 13:03:33 -0700
Branch: REL_13_STABLE [81ce00006] 2023-07-13 13:03:34 -0700
Branch: REL_12_STABLE [034a9fcd2] 2023-07-13 13:03:36 -0700
Branch: REL_11_STABLE [1c38e7ae1] 2023-07-13 13:03:37 -0700
-->
     <para>
      Avoid leaving a corrupted database behind when <command>DROP
      DATABASE</command> is interrupted (Andres Freund)
     </para>

     <para>
      If <command>DROP DATABASE</command> was interrupted after it had
      already begun taking irreversible steps, the target database
      remained accessible (because the removal of
      its <structname>pg_database</structname> row would roll back),
      but it would have corrupt contents.  Fix by marking the database
      as inaccessible before we begin to perform irreversible operations.
      A failure after that will leave the database still partially
      present, but nothing can be done with it except to issue
      another <command>DROP DATABASE</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [cfc43aeb3] 2023-06-30 13:54:48 +0900
Branch: REL_16_STABLE [f4691e2e7] 2023-06-30 13:54:53 +0900
Branch: REL_15_STABLE [cb4ac3e56] 2023-06-30 13:54:55 +0900
Branch: REL_14_STABLE [663b35f2d] 2023-06-30 13:54:56 +0900
Branch: REL_13_STABLE [537b70b82] 2023-06-30 13:54:59 +0900
Branch: REL_12_STABLE [dbe0e5c56] 2023-06-30 13:55:02 +0900
Branch: REL_11_STABLE [c75c33de5] 2023-06-30 13:55:07 +0900
-->
     <para>
      Ensure that partitioned indexes are correctly marked as valid or not
      at creation (Michael Paquier)
     </para>

     <para>
      If a new partitioned index matches an existing but invalid index on
      one of the partitions, the partitioned index could end up being
      marked valid prematurely.  This could lead to misbehavior or
      assertion failures in subsequent queries on the partitioned table.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_16_BR [fc55c7ff8] 2023-06-28 15:57:31 +0900
Branch: REL_15_STABLE [7aa17b498] 2023-06-28 15:57:43 +0900
Branch: REL_14_STABLE [6160e221d] 2023-06-28 15:57:48 +0900
Branch: REL_13_STABLE [f42844069] 2023-06-28 15:57:51 +0900
Branch: REL_12_STABLE [63b292e73] 2023-06-28 15:57:53 +0900
Branch: REL_11_STABLE [e90e9275f] 2023-06-28 15:57:55 +0900
-->
     <para>
      Ignore invalid child indexes when matching partitioned indexes to
      child indexes during <command>ALTER TABLE ATTACH PARTITION</command>
      (Michael Paquier)
     </para>

     <para>
      Such an index will now be ignored, and a new child index created
      instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [38ea6aa90] 2023-07-14 10:12:48 +0900
Branch: REL_16_STABLE [31f9d41d6] 2023-07-14 10:13:14 +0900
Branch: REL_15_STABLE [c0dc97c7b] 2023-07-14 10:13:15 +0900
Branch: REL_14_STABLE [954cc2139] 2023-07-14 10:13:17 +0900
Branch: REL_13_STABLE [c89d74c18] 2023-07-14 10:13:20 +0900
Branch: REL_12_STABLE [f1d6bcdd8] 2023-07-14 10:13:21 +0900
Branch: REL_11_STABLE [ed2b58c15] 2023-07-14 10:13:22 +0900
-->
     <para>
      Fix possible failure when marking a partitioned index valid after
      all of its partitions have been attached (Michael Paquier)
     </para>

     <para>
      The update of the index's <structname>pg_index</structname> entry
      could use stale data for other columns.  One reported symptom is
      an <quote>attempted to update invisible tuple</quote> error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [bd5ddbe86] 2023-07-10 09:40:07 +0900
Branch: REL_16_STABLE [55c95f24c] 2023-07-10 09:40:12 +0900
Branch: REL_15_STABLE [d1e0f408c] 2023-07-10 09:40:14 +0900
Branch: REL_14_STABLE [235e716bc] 2023-07-10 09:40:15 +0900
Branch: REL_13_STABLE [f5b075adc] 2023-07-10 09:40:17 +0900
Branch: REL_12_STABLE [02021f1b2] 2023-07-10 09:40:22 +0900
Branch: REL_11_STABLE [914e72e6e] 2023-07-10 09:40:24 +0900
-->
     <para>
      Fix <command>ALTER EXTENSION SET SCHEMA</command> to complain if the
      extension contains any objects outside the extension's schema
      (Michael Paquier, Heikki Linnakangas)
     </para>

     <para>
      Erroring out if the extension contains objects in multiple schemas
      was always intended; but the check was mis-coded so that it would
      fail to detect some cases, leading to surprising behavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master Release: REL_16_BR [7fcd7ef2a] 2023-06-19 13:00:42 +1200
Branch: REL_15_STABLE [8f2ec8cc7] 2023-06-19 13:01:29 +1200
Branch: REL_14_STABLE [73f1c17fc] 2023-06-19 13:01:58 +1200
Branch: REL_13_STABLE [06286f8a2] 2023-06-19 13:02:24 +1200
Branch: REL_12_STABLE [dcef5b052] 2023-06-19 13:02:52 +1200
Branch: REL_11_STABLE [f6345f03f] 2023-06-19 13:03:17 +1200
-->
     <para>
      Don't use partial unique indexes for uniqueness proofs in the
      planner (David Rowley)
     </para>

     <para>
      This could give rise to incorrect plans, since the presumed
      uniqueness of rows read from a table might not hold if the index in
      question isn't used to scan the table.
     </para>
    </listitem>

    <listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [6f80a8d9c] 2023-07-28 15:45:00 +0900
Branch: REL_16_STABLE [695f5deb7] 2023-07-28 15:45:01 +0900
Branch: REL_15_STABLE [d1ef5631e] 2023-07-28 15:45:02 +0900
Branch: REL_14_STABLE [b0e390e6d] 2023-07-28 15:45:04 +0900
Branch: REL_13_STABLE [730f983ef] 2023-07-28 15:45:06 +0900
Branch: REL_12_STABLE [9edf72aa7] 2023-07-28 15:45:08 +0900
Branch: REL_11_STABLE [db01f2696] 2023-07-28 15:45:09 +0900
-->
     <para>
      Avoid producing incorrect plans for foreign joins with
      pseudoconstant join clauses (Etsuro Fujita)
     </para>

     <para>
      The planner currently lacks support for attaching pseudoconstant
      join clauses to a pushed-down remote join, so disable generation
      of remote joins in such cases.  (A better solution will require
      ABI-breaking changes of planner data structures, so it will have to
      wait for a future major release.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [792213f2e] 2023-06-13 15:58:43 -0400
Branch: REL_15_STABLE [cc6974df1] 2023-06-13 15:58:37 -0400
Branch: REL_14_STABLE [d1423c52e] 2023-06-13 15:58:37 -0400
Branch: REL_13_STABLE [a36d0014f] 2023-06-13 15:58:37 -0400
Branch: REL_12_STABLE [b4110bdbf] 2023-06-13 15:58:37 -0400
Branch: REL_11_STABLE [13192a324] 2023-06-13 15:58:37 -0400
-->
     <para>
      Correctly handle sub-SELECTs in RLS policy expressions and
      security-barrier views when expanding rule actions (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [126552c85] 2023-07-04 09:07:31 +1200
Branch: REL_16_STABLE [12529028a] 2023-07-04 09:04:35 +1200
Branch: REL_15_STABLE [d34aa0a2f] 2023-07-04 09:10:37 +1200
Branch: REL_14_STABLE [fb663f387] 2023-07-04 09:14:16 +1200
Branch: REL_13_STABLE [fc1547384] 2023-07-04 09:20:55 +1200
Branch: REL_12_STABLE [255a925d3] 2023-07-04 09:21:33 +1200
Branch: REL_11_STABLE [13f127800] 2023-07-04 09:40:30 +1200
Branch: master [bcc93a389] 2023-07-04 09:07:31 +1200
Branch: REL_16_STABLE [d03d9a261] 2023-07-04 09:04:35 +1200
Branch: REL_15_STABLE [ab265e985] 2023-07-04 09:10:37 +1200
Branch: REL_14_STABLE [3f7d3a77e] 2023-07-04 09:14:16 +1200
Branch: REL_13_STABLE [8976ac5c5] 2023-07-04 09:20:55 +1200
Branch: REL_12_STABLE [17b8887c2] 2023-07-04 09:21:33 +1200
Branch: REL_11_STABLE [814f3c8e4] 2023-07-04 09:40:30 +1200
Branch: master [f9b7fc651] 2023-07-04 09:07:31 +1200
Branch: REL_16_STABLE [0cb1fb2c9] 2023-07-04 09:04:35 +1200
Branch: REL_15_STABLE [0f275b0ee] 2023-07-04 09:10:37 +1200
Branch: REL_14_STABLE [ae6d536ed] 2023-07-04 09:14:16 +1200
Branch: REL_13_STABLE [8f705d7b9] 2023-07-04 09:20:55 +1200
Branch: REL_12_STABLE [fe88497b4] 2023-07-04 09:21:33 +1200
Branch: REL_11_STABLE [0048c3b51] 2023-07-04 09:27:00 +1200
-->
     <para>
      Fix race conditions in conflict detection
      for <literal>SERIALIZABLE</literal> isolation mode
      (Thomas Munro)
     </para>

     <para>
      Conflicts could be missed when using bitmap heap scans, when using
      GIN indexes, and when examining an initially-empty btree index.
      All these cases could lead to serializability failures due to
      improperly allowing conflicting transactions to commit.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [45392626c] 2023-06-20 17:47:53 -0400
Branch: REL_15_STABLE [c2f974fff] 2023-06-20 17:47:53 -0400
Branch: REL_14_STABLE [d911dce14] 2023-06-20 17:47:36 -0400
Branch: REL_13_STABLE [2f97105e9] 2023-06-20 17:47:36 -0400
Branch: REL_12_STABLE [9529b1eb1] 2023-06-20 17:47:36 -0400
-->
     <para>
      Fix hash join with an inner-side hash key that contains Params
      coming from an outer nested loop (Tom Lane)
     </para>

     <para>
      When rescanning the join after the values of such Params have
      changed, we must rebuild the hash table, but neglected to do so.
      This could result in missing join output rows.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [43af714de] 2023-06-29 10:19:10 -0400
Branch: REL_15_STABLE [cc8cca3c2] 2023-06-29 10:19:10 -0400
Branch: REL_14_STABLE [0789b82a9] 2023-06-29 10:19:10 -0400
Branch: REL_13_STABLE [d0ab203bc] 2023-06-29 10:19:10 -0400
Branch: REL_12_STABLE [53b93e853] 2023-06-29 10:19:10 -0400
Branch: REL_11_STABLE [7f11b7a9c] 2023-06-29 10:19:10 -0400
-->
     <para>
      Fix intermittent failures when trying to update a field of a
      composite column (Tom Lane)
     </para>

     <para>
      If the overall value of the composite column is wide enough to
      require out-of-line toasting, then an unluckily-timed cache flush
      could cause errors or server crashes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master Release: REL_16_BR [f24523672] 2023-06-07 18:54:34 +0200
Branch: REL_15_STABLE [ee87f8b63] 2023-06-07 18:52:21 +0200
Branch: REL_14_STABLE [7f528e96c] 2023-06-07 18:53:04 +0200
Branch: REL_13_STABLE [c504aa857] 2023-06-07 18:53:16 +0200
Branch: REL_12_STABLE [54e1b8587] 2023-06-07 18:53:30 +0200
Branch: master [ce5aaea8c] 2023-07-02 22:21:02 +0200
Branch: REL_16_STABLE [9cf85093b] 2023-07-02 22:22:31 +0200
Branch: REL_15_STABLE [7ae4e7868] 2023-07-02 22:22:50 +0200
Branch: REL_14_STABLE [260dbf19a] 2023-07-02 22:23:04 +0200
Branch: REL_13_STABLE [984c23f6f] 2023-07-02 22:23:20 +0200
-->
     <para>
      Prevent query-lifespan memory leaks in some <command>UPDATE</command>
      queries with triggers (Tomas Vondra)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [98640f960] 2023-07-02 20:03:30 +0200
Branch: REL_16_STABLE [9ae7b5d1f] 2023-07-02 20:04:16 +0200
Branch: REL_15_STABLE [0c5fe4ff6] 2023-07-02 20:04:40 +0200
Branch: REL_14_STABLE [c1affa38c] 2023-07-02 20:05:14 +0200
Branch: REL_13_STABLE [3ce761d5c] 2023-07-02 20:05:35 +0200
-->
     <para>
      Prevent query-lifespan memory leaks when an Incremental Sort plan
      node is rescanned (James Coleman, Laurenz Albe, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [7398e2722] 2023-06-12 10:54:44 -0400
Branch: REL_15_STABLE [bd590d1fe] 2023-06-12 10:54:28 -0400
Branch: REL_14_STABLE [5eaa05f63] 2023-06-12 10:54:28 -0400
Branch: REL_13_STABLE [6f23b5f74] 2023-06-12 10:54:28 -0400
-->
     <para>
      Accept fractional seconds in the input to <type>jsonpath</type>'s
      <function>datetime()</function> method (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [691594acd] 2023-06-24 17:18:08 -0400
Branch: REL_15_STABLE [a77d90171] 2023-06-24 17:18:08 -0400
Branch: REL_14_STABLE [4c61afa47] 2023-06-24 17:18:08 -0400
Branch: REL_13_STABLE [b6ab18a99] 2023-06-24 17:18:08 -0400
Branch: REL_12_STABLE [3b4580f5c] 2023-06-24 17:18:08 -0400
Branch: REL_11_STABLE [c7f33a197] 2023-06-24 17:18:08 -0400
-->
     <para>
      Prevent stack-overflow crashes with very complex text search
      patterns (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [38df84c65] 2023-07-27 11:56:35 -0400
Branch: REL_16_STABLE [de3f0e3fe] 2023-07-27 11:56:35 -0400
Branch: REL_15_STABLE [313ceda2f] 2023-07-27 12:07:48 -0400
Branch: REL_14_STABLE [341996248] 2023-07-27 12:07:48 -0400
Branch: REL_13_STABLE [288b4288c] 2023-07-27 12:07:48 -0400
Branch: REL_12_STABLE [0660f74e8] 2023-07-27 12:07:48 -0400
Branch: REL_11_STABLE [1d031ad54] 2023-07-27 12:07:48 -0400
-->
     <para>
      Allow tokens up to 10240 bytes long
      in <filename>pg_hba.conf</filename>
      and <filename>pg_ident.conf</filename> (Tom Lane)
     </para>

     <para>
      The previous limit of 256 bytes has been found insufficient for some
      use-cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [4f4d73466] 2023-07-05 13:13:13 +0300
Branch: REL_16_STABLE [dc0b58417] 2023-07-05 13:25:59 +0300
Branch: REL_15_STABLE [fa96a74a0] 2023-07-05 13:13:30 +0300
Branch: REL_14_STABLE [bfb493dba] 2023-07-05 13:13:35 +0300
Branch: REL_13_STABLE [59c2a6fe9] 2023-07-05 13:13:39 +0300
Branch: REL_12_STABLE [162aa47c3] 2023-07-05 13:14:24 +0300
Branch: REL_11_STABLE [2316ff1ae] 2023-07-05 13:14:33 +0300
-->
     <para>
      Fix mishandling of C++ out-of-memory conditions (Heikki Linnakangas)
     </para>

     <para>
      If JIT is in use, running out of memory in a
      C++ <function>new</function> call would lead to
      a <productname>PostgreSQL</productname> FATAL error, instead of the
      expected C++ exception.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9089287aa] 2023-07-20 14:23:46 -0400
Branch: REL_16_STABLE [c0f531396] 2023-07-20 14:23:46 -0400
Branch: REL_15_STABLE [fbaf65cd6] 2023-07-20 14:23:46 -0400
Branch: REL_14_STABLE [10fd061bb] 2023-07-20 14:23:46 -0400
Branch: REL_13_STABLE [291c02540] 2023-07-20 14:23:46 -0400
-->
     <para>
      Fix rare null-pointer crash in <filename>plancache.c</filename>
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [03f80daac] 2023-07-04 15:16:47 +1200
Branch: REL_16_STABLE [af8f9ec66] 2023-07-04 15:21:36 +1200
Branch: REL_15_STABLE [9ffb10f18] 2023-07-04 15:24:42 +1200
Branch: REL_14_STABLE [b7ec66731] 2023-07-04 15:26:42 +1200
Branch: REL_13_STABLE [a0003572f] 2023-07-04 15:28:29 +1200
Branch: REL_12_STABLE [74ad9b0d1] 2023-07-04 15:29:41 +1200
Branch: REL_11_STABLE [1605623ec] 2023-07-04 16:13:12 +1200
-->
     <para>
      Avoid losing track of possibly-useful shared memory segments when a
      page free results in coalescing ranges of free space (Dongming Liu)
     </para>

     <para>
      Ensure that the segment is moved into the
      appropriate <quote>bin</quote> for its new amount of free space, so
      that it will be found by subsequent searches.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master Release: REL_16_BR [5f0762f14] 2023-06-21 17:41:58 -0700
Branch: REL_15_STABLE [642bec1f8] 2023-06-21 17:41:56 -0700
Branch: REL_14_STABLE [63fa0deb3] 2023-06-21 17:41:54 -0700
Branch: REL_13_STABLE [b6311824f] 2023-06-21 17:41:52 -0700
Branch: REL_12_STABLE [355917c07] 2023-06-21 17:41:50 -0700
Branch: REL_11_STABLE [7ddba19eb] 2023-06-21 17:41:48 -0700
Branch: master Release: REL_16_BR [5abff197c] 2023-05-25 15:33:00 -0700
Branch: REL_15_STABLE [6983a5112] 2023-05-25 15:32:57 -0700
Branch: REL_14_STABLE [322c9b340] 2023-05-25 15:32:53 -0700
Branch: REL_13_STABLE [8f876d15c] 2023-05-25 15:32:50 -0700
Branch: REL_12_STABLE [188dad680] 2023-05-25 15:32:48 -0700
Branch: REL_11_STABLE [a72b503ca] 2023-05-25 15:32:45 -0700
-->
     <para>
      Allow <command>VACUUM</command> to continue after detecting certain
      types of b-tree index corruption (Peter Geoghegan)
     </para>

     <para>
      If an invalid sibling-page link is detected, log the issue and press
      on, rather than throwing an error as before.  Nothing short
      of <command>REINDEX</command> will fix the broken index, but
      preventing <command>VACUUM</command> from completing until that is
      done risks making matters far worse.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [83ecfa9fa] 2023-07-13 13:03:28 -0700
Branch: REL_16_STABLE [03ccc9569] 2023-07-13 13:03:30 -0700
Branch: REL_15_STABLE [82e97b864] 2023-07-13 13:03:31 -0700
Branch: REL_14_STABLE [e246fd423] 2023-07-13 13:03:33 -0700
Branch: REL_13_STABLE [53336e8f6] 2023-07-13 13:03:34 -0700
Branch: REL_12_STABLE [7aec84e4c] 2023-07-13 13:03:36 -0700
Branch: REL_11_STABLE [1386f0987] 2023-07-13 13:03:37 -0700
-->
     <para>
      Ensure that <varname>WrapLimitsVacuumLock</varname> is released
      after <command>VACUUM</command> detects invalid data
      in <structname>pg_database</structname>.<structfield>datfrozenxid</structfield>
      or <structname>pg_database</structname>.<structfield>datminmxid</structfield>
      (Andres Freund)
     </para>

     <para>
      Failure to release this lock could lead to a deadlock later,
      although the lock would be cleaned up if the session exits or
      encounters some other error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [cb0cca188] 2023-07-18 13:43:44 +0900
Branch: REL_16_STABLE [f88bc9f38] 2023-07-18 13:44:27 +0900
Branch: REL_15_STABLE [a878eff6b] 2023-07-18 13:44:29 +0900
Branch: REL_14_STABLE [442749100] 2023-07-18 13:44:31 +0900
Branch: REL_13_STABLE [db59108a2] 2023-07-18 13:44:33 +0900
Branch: REL_12_STABLE [d2ee542a2] 2023-07-18 13:44:34 +0900
Branch: REL_11_STABLE [bc0581f8f] 2023-07-18 13:44:35 +0900
Branch: master [4e465aac3] 2023-07-18 14:04:31 +0900
Branch: REL_16_STABLE [926aa6d11] 2023-07-18 14:04:46 +0900
Branch: REL_15_STABLE [f6ecd2622] 2023-07-18 14:04:48 +0900
Branch: REL_14_STABLE [763d26205] 2023-07-18 14:04:50 +0900
Branch: REL_13_STABLE [b3ca4f0a5] 2023-07-18 14:04:51 +0900
Branch: REL_12_STABLE [410a0d6bd] 2023-07-18 14:04:52 +0900
Branch: REL_11_STABLE [6c7bffc09] 2023-07-18 14:04:54 +0900
-->
     <para>
      Avoid double replay of prepared transactions during crash
      recovery (suyu.cmj, Michael Paquier)
     </para>

     <para>
      After a crash partway through a checkpoint with some two-phase
      transaction state data already flushed to disk by this checkpoint,
      crash recovery could attempt to replay the prepared transaction(s)
      twice, leading to a fatal error such as <quote>lock is already
      held</quote> in the startup process.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_14_STABLE [f663b0091] 2023-06-20 09:36:35 +0900
Branch: REL_13_STABLE [896012b88] 2023-06-20 09:36:58 +0900
-->
     <para>
      Fix possible failure while promoting a standby server, if archiving
      is enabled and two-phase transactions need to be recovered (Julian
      Markwort)
     </para>

     <para>
      If any required two-phase transactions were logged in the most
      recent (partial) log segment, promotion would fail with an incorrect
      complaint about <quote>requested WAL segment has already been
      removed</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [4b4798e13] 2023-07-04 17:57:03 +0300
Branch: REL_16_STABLE [d431644b4] 2023-07-04 18:04:27 +0300
Branch: REL_15_STABLE [e24c02e4d] 2023-07-04 18:07:27 +0300
Branch: REL_14_STABLE [d85bf0719] 2023-07-04 18:07:46 +0300
Branch: REL_13_STABLE [acc8cdff4] 2023-07-04 18:08:08 +0300
Branch: REL_12_STABLE [1b4f1c6f8] 2023-07-04 18:08:26 +0300
Branch: REL_11_STABLE [6377f705c] 2023-07-04 18:08:40 +0300
-->
     <para>
      Ensure that a newly created, but still empty table
      is <function>fsync</function>'ed at the next checkpoint (Heikki
      Linnakangas)
     </para>

     <para>
      Without this, if there is an operating system crash causing the
      empty file to disappear, subsequent operations on the table might
      fail with <quote>could not open file</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [3142a8845] 2023-07-06 17:25:29 +0300
Branch: REL_16_STABLE [bf7b70e6b] 2023-07-06 17:28:50 +0300
Branch: REL_15_STABLE [25624c5d3] 2023-07-06 17:29:12 +0300
Branch: REL_14_STABLE [32f327f68] 2023-07-06 17:29:13 +0300
Branch: REL_13_STABLE [c50b869ed] 2023-07-06 17:29:14 +0300
Branch: REL_12_STABLE [80abec387] 2023-07-06 17:29:15 +0300
Branch: REL_11_STABLE [988719b88] 2023-07-06 17:29:16 +0300
-->
     <para>
      Ensure that creation of the init fork of an unlogged index is
      WAL-logged (Heikki Linnakangas)
     </para>

     <para>
      While an unlogged index's main data fork is not WAL-logged, its init
      fork should be, to ensure that we have a consistent state to restore
      the index to after a crash.  This step was missed if the init fork
      contains no data, which is a case not used by any standard index AM;
      but perhaps some extension behaves that way.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_14_STABLE [c6043fcbb] 2023-06-11 10:33:46 +0900
Branch: REL_13_STABLE [37236ca06] 2023-06-11 10:33:56 +0900
Branch: REL_12_STABLE [9920552e1] 2023-06-11 10:33:59 +0900
Branch: REL_11_STABLE [a9c3472e0] 2023-06-11 10:34:00 +0900
-->
     <para>
      Fix missing reinitializations of delay-checkpoint-end flags
      (suyu.cmj)
     </para>

     <para>
      This could result in unnecessary delays of checkpoints, or in
      assertion failures in assert-enabled builds.
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [deae1657e] 2023-08-02 01:39:47 +1200
Branch: REL_16_STABLE [b25acc302] 2023-08-02 01:40:27 +1200
Branch: REL_15_STABLE [67f3a697b] 2023-08-02 01:40:56 +1200
Branch: REL_14_STABLE [f457f2ef1] 2023-08-02 01:41:21 +1200
Branch: REL_13_STABLE [74a5bf1b6] 2023-08-02 01:41:55 +1200
Branch: REL_12_STABLE [668990980] 2023-08-02 01:44:31 +1200
-->
     <para>
      Fix overly strict assertion in <type>jsonpath</type> code
      (David Rowley)
     </para>

     <para>
      This assertion failed if a query applied
      the <literal>.type()</literal> operator to
      a <literal>like_regex</literal> result.
      There was no bug in non-assert builds.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [555b929bb] 2023-06-21 11:07:24 -0400
Branch: REL_15_STABLE [cb74f7bec] 2023-06-21 11:07:11 -0400
Branch: REL_14_STABLE [120ea65b8] 2023-06-21 11:07:11 -0400
Branch: REL_13_STABLE [d1fc0f382] 2023-06-21 11:07:11 -0400
Branch: REL_12_STABLE [a98a04005] 2023-06-21 11:07:11 -0400
Branch: REL_11_STABLE [a8be2356c] 2023-06-21 11:07:11 -0400
-->
     <para>
      Avoid assertion failure when processing an empty statement via the
      extended query protocol in an already-aborted transaction (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_16_BR [1d369c9e9] 2023-05-16 10:53:42 -0400
Branch: REL_15_STABLE [eaf99e4c4] 2023-05-16 10:53:42 -0400
Branch: REL_14_STABLE [ccd362325] 2023-05-16 10:53:42 -0400
Branch: REL_13_STABLE [0409c7fc7] 2023-05-16 10:53:42 -0400
Branch: REL_12_STABLE [0966291a4] 2023-05-16 10:53:42 -0400
Branch: REL_11_STABLE [8084bf9a4] 2023-05-16 10:53:42 -0400
-->
     <para>
      Fix <filename>contrib/fuzzystrmatch</filename>'s
      Soundex <function>difference()</function> function to handle empty
      input sanely (Alexander Lakhin, Tom Lane)
     </para>

     <para>
      An input string containing no alphabetic characters resulted in
      unpredictable output.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_16_BR [d522b05c8] 2023-06-12 09:14:03 +0900
Branch: REL_15_STABLE [3a5222a43] 2023-06-12 09:14:13 +0900
Branch: REL_14_STABLE [e0e682945] 2023-06-12 09:14:14 +0900
Branch: REL_13_STABLE [78bf0a256] 2023-06-12 09:14:17 +0900
Branch: REL_12_STABLE [edf1de65e] 2023-06-12 09:14:19 +0900
Branch: REL_11_STABLE [bbfc26d86] 2023-06-12 09:14:20 +0900
-->
     <para>
      Tighten whitespace checks in <filename>contrib/hstore</filename>
      input (Evan Jones)
     </para>

     <para>
      In some cases, characters would be falsely recognized as whitespace
      and hence discarded.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_16_BR [c00fbe89d] 2023-06-15 13:45:34 +0900
Branch: REL_15_STABLE [4be308ede] 2023-06-15 13:45:38 +0900
Branch: REL_14_STABLE [019a40d61] 2023-06-15 13:45:40 +0900
Branch: REL_13_STABLE [ae9aac64a] 2023-06-15 13:45:41 +0900
Branch: REL_12_STABLE [6ecc1c02a] 2023-06-15 13:45:42 +0900
Branch: REL_11_STABLE [ab40b0395] 2023-06-15 13:45:44 +0900
-->
     <para>
      Disallow oversize input arrays
      with <filename>contrib/intarray</filename>'s
      <literal>gist__int_ops</literal> index opclass (Ankit Kumar Pandey,
      Alexander Lakhin)
     </para>

     <para>
      Previously this code would report a <literal>NOTICE</literal> but
      press on anyway, creating an invalid index entry that presents a
      risk of crashes when the index is read.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8aac9759b] 2023-07-13 13:07:51 -0400
Branch: REL_16_STABLE [e27f3f52c] 2023-07-13 13:08:08 -0400
Branch: REL_15_STABLE [5cb461989] 2023-07-13 13:08:17 -0400
Branch: REL_14_STABLE [a6991f763] 2023-07-13 13:08:23 -0400
Branch: REL_13_STABLE [7fffcc2ee] 2023-07-13 13:08:28 -0400
Branch: REL_12_STABLE [8d8f37149] 2023-07-13 13:08:33 -0400
Branch: REL_11_STABLE [9f70f6d4c] 2023-07-13 13:08:40 -0400
-->
     <para>
      Avoid useless double decompression of GiST index entries
      in <filename>contrib/intarray</filename> (Konstantin Knizhnik,
      Matthias van de Meent, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [a5ea825f9] 2023-07-14 11:15:34 +0900
Branch: REL_16_STABLE [27da47122] 2023-07-14 11:16:03 +0900
Branch: REL_15_STABLE [eb3abec4b] 2023-07-14 11:16:06 +0900
Branch: REL_14_STABLE [7af65523a] 2023-07-14 11:16:08 +0900
Branch: REL_13_STABLE [bdaaf1bf1] 2023-07-14 11:16:10 +0900
Branch: REL_12_STABLE [7d27493b7] 2023-07-14 11:16:11 +0900
Branch: REL_11_STABLE [db9813819] 2023-07-14 11:16:13 +0900
-->
     <para>
      Ensure
      that <structname>pg_index</structname>.<structfield>indisreplident</structfield>
      is kept up-to-date in relation cache entries (Shruthi Gowda)
     </para>

     <para>
      This value could be stale in some cases.  There is no core code that
      relies on the relation cache's copy, so this is only a latent bug as
      far as Postgres itself is concerned; but there may be extensions for
      which it is a live bug.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: REL_13_STABLE [8aa9a2623] 2023-06-24 20:22:57 +0900
Branch: REL_12_STABLE [265c9138d] 2023-06-24 20:26:56 +0900
Branch: REL_11_STABLE [96f96398d] 2023-06-24 20:29:42 +0900
-->
     <para>
      Silence deprecation warnings when compiling with OpenSSL 3.0.0 or
      later (Peter Eisentraut)
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-11">
  <title>Release 13.11</title>

  <formalpara>
  <title>Release date:</title>
  <para>2023-05-11</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.10.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.11</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you are upgrading from a version earlier than 13.7,
    see <xref linkend="release-13-7"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [681d9e462] 2023-05-08 06:14:07 -0700
Branch: REL_15_STABLE [dbd5795e7] 2023-05-08 06:14:11 -0700
Branch: REL_14_STABLE [01e8182c7] 2023-05-08 06:14:11 -0700
Branch: REL_13_STABLE [2212f7db8] 2023-05-08 06:14:12 -0700
Branch: REL_12_STABLE [78119a0bf] 2023-05-08 06:14:12 -0700
Branch: REL_11_STABLE [23cb8eaeb] 2023-05-08 06:14:12 -0700
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8d525d7b9] 2023-05-08 11:24:47 -0400
Branch: REL_15_STABLE [1b761d896] 2023-05-08 11:24:47 -0400
Branch: REL_14_STABLE [1913f63dc] 2023-05-08 11:24:47 -0400
Branch: REL_13_STABLE [feb9e7fbb] 2023-05-08 11:24:47 -0400
Branch: REL_12_STABLE [2cd843cc9] 2023-05-08 11:24:47 -0400
Branch: REL_11_STABLE [766e06140] 2023-05-08 11:24:47 -0400
-->
     <para>
      Prevent <command>CREATE SCHEMA</command> from defeating changes
      in <varname>search_path</varname> (Alexander Lakhin)
     </para>

     <para>
      Within a <command>CREATE SCHEMA</command> command, objects in the
      prevailing <varname>search_path</varname>, as well as those in the
      newly-created schema, would be visible even within a called
      function or script that attempted to set a
      secure <varname>search_path</varname>.  This could allow any user
      having permission to create a schema to hijack the privileges of a
      security definer function or extension script.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Alexander Lakhin for reporting this problem.
      (CVE-2023-2454)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ca73753b0] 2023-05-08 10:12:44 -0400
Branch: REL_15_STABLE [04e560604] 2023-05-08 10:12:44 -0400
Branch: REL_14_STABLE [f8d799eda] 2023-05-08 10:12:44 -0400
Branch: REL_13_STABLE [b8e28f04f] 2023-05-08 10:12:44 -0400
Branch: REL_12_STABLE [ee87b482c] 2023-05-08 10:12:45 -0400
Branch: REL_11_STABLE [473626cf0] 2023-05-08 10:12:45 -0400
-->
     <para>
      Enforce row-level security policies correctly after inlining a
      set-returning function (Stephen Frost, Tom Lane)
     </para>

     <para>
      If a set-returning SQL-language function refers to a table having
      row-level security policies, and it can be inlined into a calling
      query, those RLS policies would not get enforced properly in some
      cases involving re-using a cached plan under a different role.
      This could allow a user to see or modify rows that should have been
      invisible.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Wolfgang Walther for reporting this problem.
      (CVE-2023-2455)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [4dadd660f] 2023-04-28 19:29:12 +0900
Branch: REL_15_STABLE [b9ad73ad2] 2023-04-28 19:29:36 +0900
Branch: REL_14_STABLE [d29eba198] 2023-04-28 19:29:38 +0900
Branch: REL_13_STABLE [7e95a33b4] 2023-04-28 19:29:40 +0900
Branch: REL_12_STABLE [63f7e91ec] 2023-04-28 19:29:42 +0900
Branch: REL_11_STABLE [a9212716b] 2023-04-28 19:29:44 +0900
-->
     <para>
      Avoid crash when the new schema name is omitted
      in <command>CREATE SCHEMA</command> (Michael Paquier)
     </para>

     <para>
      The SQL standard allows writing <literal>CREATE SCHEMA AUTHORIZATION
      <replaceable>owner_name</replaceable></literal>, with the schema
      name defaulting to <replaceable>owner_name</replaceable>.  However
      some code paths expected the schema name to be present and would
      fail.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4766eef31] 2023-04-05 12:56:32 -0400
Branch: REL_15_STABLE [2624de79e] 2023-04-05 12:56:30 -0400
Branch: REL_14_STABLE [0a6aaf011] 2023-04-05 12:56:30 -0400
Branch: REL_13_STABLE [b02bf1e46] 2023-04-05 12:56:30 -0400
Note: no live bug fixed in v15 or HEAD
-->
     <para>
      Fix enabling/disabling of cloned triggers in partitioned tables
      (Tom Lane)
     </para>

     <para>
      <command>ALTER TABLE ... ENABLE/DISABLE TRIGGER USER</command>
      skipped cloned triggers, mistaking them for system triggers.
      Other variants of <literal>ENABLE/DISABLE TRIGGER</literal> would
      process them, but only after improperly enforcing a superuserness
      check.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a3c9d35ae] 2023-03-27 15:04:15 -0400
Branch: REL_15_STABLE [d90d59e25] 2023-03-27 15:04:02 -0400
Branch: REL_14_STABLE [334cc4c96] 2023-03-27 15:04:02 -0400
Branch: REL_13_STABLE [29a20ff06] 2023-03-27 15:04:02 -0400
Branch: REL_12_STABLE [cd07163c0] 2023-03-27 15:04:02 -0400
Branch: REL_11_STABLE [78838bc3d] 2023-03-27 15:04:02 -0400
-->
     <para>
      Disallow altering composite types that are stored in indexes
      (Tom Lane)
     </para>

     <para>
      <command>ALTER TYPE</command> disallows non-binary-compatible
      modifications of composite types if they are stored in any table
      columns.  (Perhaps that will be allowed someday, but it hasn't
      happened yet; the locking implications of rewriting many tables are
      daunting.)  We overlooked the possibility that an index might
      contain a composite type that doesn't also appear in its table.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f0d65c0ea] 2023-03-31 11:18:49 -0400
Branch: REL_15_STABLE [6e3698173] 2023-03-31 11:18:49 -0400
Branch: REL_14_STABLE [b0b55d8b8] 2023-03-31 11:18:49 -0400
Branch: REL_13_STABLE [bfb993b1b] 2023-03-31 11:18:49 -0400
Branch: REL_12_STABLE [e8d74aac5] 2023-03-31 11:18:49 -0400
-->
     <para>
      Disallow system columns as elements of foreign keys (Tom Lane)
     </para>

     <para>
      Since the removal of OID as a system column, there is no plausible
      use-case for this, and various bits of code no longer support it.
      Disallow it rather than trying to fix all the cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d66bb048c] 2023-03-10 13:52:44 -0500
Branch: REL_15_STABLE [59947bac7] 2023-03-10 13:52:28 -0500
Branch: REL_14_STABLE [53a53ea33] 2023-03-10 13:52:28 -0500
Branch: REL_13_STABLE [866fd004d] 2023-03-10 13:52:28 -0500
Branch: REL_12_STABLE [a30310833] 2023-03-10 13:52:28 -0500
Branch: REL_11_STABLE [6e2674d77] 2023-03-10 13:52:28 -0500
-->
     <para>
      Ensure that <command>COPY TO</command> from an RLS-enabled parent
      table does not copy any rows from child tables (Antonin Houska)
     </para>

     <para>
      The documentation is quite clear that <command>COPY TO</command>
      copies rows from only the named table, not any inheritance children
      it may have.  However, if row-level security was enabled on the table
      then this stopped being true.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4c40995f6] 2023-05-04 11:48:23 -0400
Branch: REL_15_STABLE [ccb479e76] 2023-05-04 11:48:23 -0400
Branch: REL_14_STABLE [d5de344a5] 2023-05-04 11:48:23 -0400
Branch: REL_13_STABLE [9a72f499a] 2023-05-04 11:48:23 -0400
Branch: REL_12_STABLE [580df5078] 2023-05-04 11:48:23 -0400
Branch: REL_11_STABLE [4624aad61] 2023-05-04 11:48:23 -0400
-->
     <para>
      Avoid possible crash when <function>array_position()</function>
      or <function>array_positions()</function> is passed an empty array
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b081fe419] 2023-03-14 19:17:31 -0400
Branch: REL_15_STABLE [a67c75f82] 2023-03-14 19:17:31 -0400
Branch: REL_14_STABLE [7cac19105] 2023-03-14 19:17:31 -0400
Branch: REL_13_STABLE [386a26023] 2023-03-14 19:17:31 -0400
Branch: REL_12_STABLE [6d3a9a60f] 2023-03-14 19:17:31 -0400
Branch: REL_11_STABLE [8e33fb9ef] 2023-03-14 19:17:31 -0400
-->
     <para>
      Fix possible out-of-bounds fetch in <function>to_char()</function>
      (Tom Lane)
     </para>

     <para>
      With bad luck this could have resulted in a server crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d7056bc1c] 2023-03-01 11:30:31 -0500
Branch: REL_15_STABLE [eae09137d] 2023-03-01 11:30:17 -0500
Branch: REL_14_STABLE [1a9356f65] 2023-03-01 11:30:17 -0500
Branch: REL_13_STABLE [3b37e8442] 2023-03-01 11:30:17 -0500
Branch: REL_12_STABLE [b162660d3] 2023-03-01 11:30:17 -0500
Branch: REL_11_STABLE [b1a9d8ef2] 2023-03-01 11:30:17 -0500
-->
     <para>
      Avoid buffer overread in <function>translate()</function> function
      (Daniil Anisimov)
     </para>

     <para>
      When using the deletion feature, the function might fetch the byte
      just after the input string, creating a small risk of crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [25a7812cd] 2023-03-13 15:19:00 -0400
Branch: REL_15_STABLE [74a1a36d7] 2023-03-13 15:19:00 -0400
Branch: REL_14_STABLE [0ee9d685d] 2023-03-13 15:19:00 -0400
Branch: REL_13_STABLE [52e9a7816] 2023-03-13 15:19:00 -0400
Branch: REL_12_STABLE [c25a929a6] 2023-03-13 15:19:00 -0400
Branch: REL_11_STABLE [234941a3b] 2023-03-13 15:19:00 -0400
-->
     <para>
      Fix error cursor setting for parse errors in JSON string literals
      (Tom Lane)
     </para>

     <para>
      Most cases in which a syntax error is detected in a string literal
      within a JSON value failed to set the error cursor appropriately.
      This led at least to an unhelpful error message (pointing to the
      token before the string, rather than the actual trouble spot), and
      could even result in a crash in v14 and later.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [be504a3e9] 2023-03-07 21:52:32 -0800
Branch: REL_15_STABLE [391f08fd6] 2023-03-07 21:36:48 -0800
Branch: REL_14_STABLE [324281fd5] 2023-03-07 21:36:49 -0800
Branch: REL_13_STABLE [e6d77f22c] 2023-03-07 21:36:51 -0800
Branch: REL_12_STABLE [3c92f7e9d] 2023-03-07 21:36:52 -0800
-->
     <para>
      Fix data corruption due to <varname>vacuum_defer_cleanup_age</varname>
      being larger than the current 64-bit xid (Andres Freund)
     </para>

     <para>
      In v14 and later with non-default settings
      of <varname>vacuum_defer_cleanup_age</varname>, it was possible to
      compute a very large vacuum cleanup horizon xid, leading to vacuum
      removing rows that are still live.  v12 and v13 have a lesser form
      of the same problem affecting only GiST indexes, which could lead to
      index pages getting recycled too early.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [30dbdbe75] 2023-03-13 12:40:28 -0400
Branch: REL_15_STABLE [5fd61bdc1] 2023-03-13 12:40:28 -0400
Branch: REL_14_STABLE [096e70805] 2023-03-13 12:40:28 -0400
Branch: REL_13_STABLE [bc0bcce2e] 2023-03-13 12:40:28 -0400
Branch: REL_12_STABLE [62a91a1b0] 2023-03-13 12:40:28 -0400
Branch: REL_11_STABLE [0736b1131] 2023-03-13 12:40:28 -0400
-->
     <para>
      Fix parser's failure to detect some cases of improperly-nested
      aggregates (Tom Lane)
     </para>

     <para>
      This oversight could lead to executor failures for queries that
      should have been rejected as invalid.
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [6c3b697b1] 2023-03-31 12:13:05 +1300
Branch: REL_15_STABLE [df567fbf6] 2023-03-31 12:13:34 +1300
Branch: REL_14_STABLE [211016220] 2023-03-31 12:14:04 +1300
Branch: REL_13_STABLE [8d684c445] 2023-03-31 12:14:31 +1300
Branch: REL_12_STABLE [33510bc64] 2023-03-31 12:15:07 +1300
Branch: REL_11_STABLE [07554c99d] 2023-03-31 12:15:39 +1300
-->
     <para>
      Fix data structure corruption during parsing of
      serial <literal>SEQUENCE NAME</literal> options (David Rowley)
     </para>

     <para>
      This can lead to trouble if an event trigger captures the corrupted
      parse tree.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [88ceac5d7] 2023-04-12 10:46:38 -0400
Branch: REL_15_STABLE [f4badbcf4] 2023-04-12 10:46:30 -0400
Branch: REL_14_STABLE [0dd55ef9b] 2023-04-12 10:46:30 -0400
Branch: REL_13_STABLE [96c698e3f] 2023-04-12 10:46:30 -0400
Branch: REL_12_STABLE [953ff99c2] 2023-04-12 10:46:30 -0400
Branch: REL_11_STABLE [60c8aeaf6] 2023-04-12 10:46:30 -0400
-->
     <para>
      Correctly update plan nodes' parallel-safety markings when moving
      initplans from one node to another (Tom Lane)
     </para>

     <para>
      This planner oversight could lead to <quote>subplan was not
      initialized</quote> errors at runtime.
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [836c31ba5] 2023-02-13 17:11:03 +1300
Branch: REL_15_STABLE [a9fa6d79a] 2023-02-13 17:10:31 +1300
Branch: REL_14_STABLE [4aa43ba21] 2023-02-13 17:09:55 +1300
Branch: REL_13_STABLE [301eb3ee4] 2023-02-13 17:09:26 +1300
Branch: REL_12_STABLE [ac55abd33] 2023-02-13 17:08:46 +1300
Branch: REL_11_STABLE [8d2a8581b] 2023-02-13 17:07:04 +1300
-->
     <para>
      Disable the inverse-transition optimization for window aggregates
      when the call contains sub-SELECTs (David Rowley)
     </para>

     <para>
      This optimization requires that the aggregate's argument expressions
      have repeatable results, which might not hold for a sub-SELECT.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [554841699] 2023-03-26 13:41:06 -0400
Branch: REL_15_STABLE [7c4873438] 2023-03-26 13:41:06 -0400
Branch: REL_14_STABLE [11213d446] 2023-03-26 13:41:06 -0400
Branch: REL_13_STABLE [1bbbe1460] 2023-03-26 13:41:06 -0400
Branch: REL_12_STABLE [ad5fe7420] 2023-03-26 13:41:06 -0400
Branch: REL_11_STABLE [ae320fc21] 2023-03-26 13:41:06 -0400
-->
     <para>
      Fix oversights in execution of nested <literal>ARRAY[]</literal>
      constructs (Alexander Lakhin, Tom Lane)
     </para>

     <para>
      Correctly detect overflow of the total space needed for the result
      array, avoiding a possible crash due to undersized output
      allocation.  Also ensure that any trailing padding space in the
      result array is zeroed; while leaving garbage there is harmless for
      most purposes, it can result in odd behavior later.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [064eb89e8] 2023-04-15 12:01:39 -0400
Branch: REL_15_STABLE [c53ed26ea] 2023-04-15 12:01:39 -0400
Branch: REL_14_STABLE [9b104a27c] 2023-04-15 12:01:39 -0400
Branch: REL_13_STABLE [7428aecdd] 2023-04-15 12:01:39 -0400
Branch: REL_12_STABLE [048caf8d7] 2023-04-15 12:01:39 -0400
-->
     <para>
      Prevent crash when updating a field within an
      array-of-domain-over-composite-type column (Dmitry Dolgov)
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [e0693faf7] 2023-04-14 16:20:27 +1200
Branch: REL_15_STABLE [0c09160e1] 2023-04-14 16:21:07 +1200
Branch: REL_14_STABLE [ae85fb828] 2023-04-14 16:21:42 +1200
Branch: REL_13_STABLE [6848f0c67] 2023-04-14 16:22:11 +1200
Branch: REL_12_STABLE [0b2e77ce2] 2023-04-14 16:22:46 +1200
Branch: REL_11_STABLE [1c19e2863] 2023-04-14 16:23:11 +1200
-->
     <para>
      Fix partition pruning logic for partitioning on boolean columns
      (David Rowley)
     </para>

     <para>
      Pruning with a condition like <literal>boolcol IS NOT TRUE</literal>
      was done incorrectly, leading to possibly not returning rows in
      which <literal>boolcol</literal> is NULL.  Also, the rather unlikely
      case of partitioning on <literal>NOT boolcol</literal> was handled
      incorrectly.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [8d578b9b2] 2023-03-21 14:29:34 +1300
Branch: REL_15_STABLE [c03c6e8cf] 2023-03-21 14:32:14 +1300
Branch: REL_14_STABLE [1b9e42e82] 2023-03-21 14:37:33 +1300
Branch: REL_13_STABLE [6e94d62e3] 2023-03-21 14:38:59 +1300
Branch: REL_12_STABLE [44d44aa97] 2023-03-21 14:41:35 +1300
Branch: REL_11_STABLE [ef16d2724] 2023-03-21 14:43:07 +1300
-->
     <para>
      Fix race condition in per-batch cleanup during parallel hash join
      (Thomas Munro, Melanie Plageman)
     </para>

     <para>
      A crash was possible given unlucky timing and
      <varname>parallel_leader_participation</varname>
      = <literal>off</literal> (which is not the default).
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7fee7871b] 2023-03-06 18:31:27 -0500
Branch: REL_15_STABLE [70ef50954] 2023-03-06 18:31:16 -0500
Branch: REL_14_STABLE [1e05ea51d] 2023-03-06 18:31:16 -0500
Branch: REL_13_STABLE [4a94cbd02] 2023-03-06 18:31:16 -0500
Branch: REL_12_STABLE [23b75dd03] 2023-03-06 18:31:16 -0500
-->
     <para>
      Recalculate <literal>GENERATED</literal> columns after an
      EvalPlanQual check (Tom Lane)
     </para>

     <para>
      In <literal>READ COMMITTED</literal> isolation mode, the effects of
      a row update might need to get reapplied to a newer version of the
      row than the query found originally.  If so, we need to recompute
      any <literal>GENERATED</literal> columns, in case they depend on
      columns that were changed by the concurrent update.
     </para>
    </listitem>

    <listitem>
<!--
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [bfac8f8bc] 2023-04-25 13:54:10 +0200
Branch: REL_15_STABLE [0319b306e] 2023-04-25 13:54:10 +0200
Branch: REL_14_STABLE [0e8e5e856] 2023-04-25 13:54:10 +0200
Branch: REL_13_STABLE [b95f36f86] 2023-04-25 13:54:10 +0200
Branch: REL_12_STABLE [cba3c8f6d] 2023-04-25 13:54:10 +0200
Branch: REL_11_STABLE [0151d2c5f] 2023-04-25 13:54:10 +0200
-->
     <para>
      Don't balance vacuum cost delay when a table has a
      per-relation <varname>vacuum_cost_delay</varname> setting of zero
      (Masahiko Sawada)
     </para>

     <para>
      Delay balancing is supposed to be disabled whenever autovacuum is
      processing a table with a
      per-relation <varname>vacuum_cost_delay</varname> setting, but this
      was done only for positive settings, not zero.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [99be6feec] 2023-03-07 18:21:53 -0500
Branch: REL_15_STABLE [76d2177fb] 2023-03-07 18:21:53 -0500
Branch: REL_14_STABLE [9f1e51b59] 2023-03-07 18:21:37 -0500
Branch: REL_13_STABLE [695b34ab3] 2023-03-07 18:21:37 -0500
Branch: REL_12_STABLE [5a19da58e] 2023-03-07 18:21:37 -0500
Branch: REL_11_STABLE [721626cb5] 2023-03-07 18:21:37 -0500
-->
     <para>
      Fix corner-case crashes when columns have been added to the end of a
      view (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [87f3667ec] 2023-02-25 14:44:14 -0500
Branch: REL_15_STABLE [a033f9165] 2023-02-25 14:44:14 -0500
Branch: REL_14_STABLE [9eaba0602] 2023-02-25 14:44:14 -0500
Branch: REL_13_STABLE [1e199c259] 2023-02-25 14:44:14 -0500
Branch: REL_12_STABLE [904b171a4] 2023-02-25 14:44:14 -0500
Branch: REL_11_STABLE [ffec64ba8] 2023-02-25 14:44:14 -0500
-->
     <para>
      Repair rare failure of MULTIEXPR_SUBLINK subplans in partitioned
      updates (Andres Freund, Tom Lane)
     </para>

     <para>
      Use of the syntax <literal>INSERT ... ON CONFLICT DO UPDATE SET (c1,
      ...) = (SELECT ...)</literal> with a partitioned target table could
      result in failure if any child table is dissimilar from the parent
      (for example, different physical column order).
      This typically manifested as failure of consistency checks in the
      executor; but a crash or incorrect data updates are also possible.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [75c737636] 2023-02-23 10:53:01 +0000
Branch: REL_15_STABLE [940b54743] 2023-02-23 10:54:51 +0000
Branch: REL_14_STABLE [f0423bea7] 2023-02-23 10:55:48 +0000
Branch: REL_13_STABLE [226da3d47] 2023-02-23 10:56:41 +0000
Branch: REL_12_STABLE [98b83b734] 2023-02-23 10:57:46 +0000
Branch: REL_11_STABLE [e68b133c3] 2023-02-23 10:58:43 +0000
-->
     <para>
      Fix handling of <literal>DEFAULT</literal> markers within a
      multi-row <literal>INSERT ... VALUES</literal> query on a view that
      has a <literal>DO ALSO INSERT ... SELECT</literal> rule (Dean
      Rasheed)
     </para>

     <para>
      Such cases typically failed with <quote>unrecognized node
      type</quote> errors or assertion failures.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [a7d71c41d] 2023-02-25 14:41:12 +0000
Branch: REL_15_STABLE [8e5b4e001] 2023-02-25 14:43:57 +0000
Branch: REL_14_STABLE [27ff93d18] 2023-02-25 14:44:49 +0000
Branch: REL_13_STABLE [39ad791e8] 2023-02-25 14:45:44 +0000
Branch: REL_12_STABLE [4fd093af7] 2023-02-25 14:47:03 +0000
Branch: REL_11_STABLE [79f194cc0] 2023-02-25 14:48:08 +0000
-->
     <para>
      Support references to <literal>OLD</literal>
      and <literal>NEW</literal> within subqueries in rule actions
      (Dean Rasheed, Tom Lane)
     </para>

     <para>
      Such references are really lateral references, but the server could
      crash if the subquery wasn't explicitly marked
      with <literal>LATERAL</literal>.  Arrange to do that implicitly when
      necessary.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [393430f57] 2023-02-17 16:40:34 -0500
Branch: REL_15_STABLE [c8a5f1685] 2023-02-17 16:40:34 -0500
Branch: REL_14_STABLE [14345f3c6] 2023-02-17 16:40:34 -0500
Branch: REL_13_STABLE [4efb4f0d4] 2023-02-17 16:40:34 -0500
Branch: REL_12_STABLE [3dd287c14] 2023-02-17 16:40:34 -0500
Branch: REL_11_STABLE [df931e9ab] 2023-02-17 16:40:34 -0500
-->
     <para>
      When decompiling a rule or SQL function body
      containing <command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>
      within <command>WITH</command>, take care to print the correct alias
      for the target table (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [47c0accbe] 2023-03-06 15:07:15 +1300
Branch: REL_15_STABLE [055990904] 2023-03-06 16:05:47 +1300
Branch: REL_14_STABLE [e9051ecd5] 2023-03-06 16:17:22 +1300
Branch: REL_13_STABLE [a0f55fc86] 2023-03-06 16:28:34 +1300
Branch: REL_12_STABLE [afa122e41] 2023-03-06 16:41:34 +1300
Branch: master [65e388d41] 2023-03-09 16:33:24 +1300
Branch: REL_15_STABLE [af397c6c2] 2023-03-09 16:56:51 +1300
Branch: REL_14_STABLE [d811d74be] 2023-03-09 16:57:11 +1300
Branch: REL_13_STABLE [ae632f7a3] 2023-03-09 17:09:57 +1300
Branch: REL_12_STABLE [e30fd0942] 2023-03-09 17:25:20 +1300
Branch: REL_11_STABLE [d1c0f81e7] 2023-03-09 17:26:06 +1300
-->
     <para>
      Fix glitches in <literal>SERIALIZABLE READ ONLY</literal>
      optimization (Thomas Munro)
     </para>

     <para>
      Transactions already marked as <quote>doomed</quote> confused the
      safe-snapshot optimization for <literal>SERIALIZABLE READ
      ONLY</literal> transactions.  The optimization was unnecessarily
      skipped in some cases.  In other cases an assertion failure occurred
      (but there was no problem in non-assert builds).
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [05172f1f3] 2023-02-23 15:40:42 -0500
Branch: REL_15_STABLE [cef1c9c0c] 2023-02-23 15:40:28 -0500
Branch: REL_14_STABLE [0f78df719] 2023-02-23 15:40:28 -0500
Branch: REL_13_STABLE [861e9e486] 2023-02-23 15:40:28 -0500
Branch: REL_12_STABLE [95558bc8f] 2023-02-23 15:40:28 -0500
Branch: REL_11_STABLE [44dbc960f] 2023-02-23 15:40:28 -0500
-->
     <para>
      Avoid leaking cache callback slots in
      the <literal>pgoutput</literal> logical decoding plugin (Shi Yu)
     </para>

     <para>
      Multiple cycles of starting up and shutting down the plugin within a
      single session would eventually lead to an <quote>out of
      relcache_callback_list slots</quote> error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [cd115c353] 2023-04-23 13:58:41 +0300
Branch: REL_15_STABLE [6e7361c85] 2023-04-23 14:00:06 +0300
Branch: REL_14_STABLE [9ef5a3583] 2023-04-23 14:00:13 +0300
Branch: REL_13_STABLE [02191136c] 2023-04-23 14:00:16 +0300
-->
     <para>
      Avoid unnecessary calls to custom validators for index operator
      class options (Alexander Korotkov)
     </para>

     <para>
      This change fixes some cases where an unexpected error was thrown.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8e5eef50c] 2023-03-29 11:31:30 -0400
Branch: REL_15_STABLE [2dc77adc7] 2023-03-29 11:31:30 -0400
Branch: REL_14_STABLE [a1904c9ce] 2023-03-29 11:31:30 -0400
Branch: REL_13_STABLE [2adb6adad] 2023-03-29 11:31:30 -0400
Branch: REL_12_STABLE [d2a1d4b19] 2023-03-29 11:31:30 -0400
Branch: REL_11_STABLE [b5c6776c1] 2023-03-29 11:31:30 -0400
-->
     <para>
      Fix dereference of dangling pointer during buffering build of a GiST
      index (Alexander Lakhin)
     </para>

     <para>
      This error seems to usually be harmless in production builds, as the
      fetched value is noncritical; but in principle it could cause a
      server crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [adedf54e6] 2023-03-23 11:58:36 +0530
Branch: REL_15_STABLE [b6bf90edc] 2023-03-23 11:46:16 +0530
Branch: REL_14_STABLE [9dac02c77] 2023-03-23 11:32:22 +0530
Branch: REL_13_STABLE [be52fff91] 2023-03-23 11:21:13 +0530
Branch: REL_12_STABLE [0f2d4adbf] 2023-03-23 11:08:38 +0530
Branch: master [b797def59] 2023-03-21 09:47:21 +0530
Branch: REL_15_STABLE [3c12407f4] 2023-03-21 09:40:41 +0530
Branch: REL_14_STABLE [65ead7696] 2023-03-21 09:18:51 +0530
Branch: REL_13_STABLE [751d6676d] 2023-03-21 09:07:37 +0530
Branch: REL_12_STABLE [fc63e6ba8] 2023-03-21 08:50:23 +0530
Branch: REL_11_STABLE [4cdaea7a2] 2023-03-21 08:39:00 +0530
-->
     <para>
      Ignore dropped columns and generated columns during logical
      replication of an update or delete action (Onder Kalaci, Shi Yu)
     </para>

     <para>
      Replication with the <literal>REPLICA IDENTITY FULL</literal> option
      failed if the table contained such columns.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [58f5edf84] 2023-05-05 21:25:44 +0900
Branch: REL_15_STABLE [d31dab9a5] 2023-05-05 21:25:50 +0900
Branch: REL_14_STABLE [ae4ffa722] 2023-05-05 21:25:56 +0900
Branch: REL_13_STABLE [cedcc4191] 2023-05-05 21:26:02 +0900
-->
     <para>
      Correct the name of the wait event for SLRU buffer I/O for commit
      timestamps (Alexander Lakhin)
     </para>

     <para>
      This wait event is named <literal>CommitTsBuffer</literal> according
      to the documentation, but the code had it
      as <literal>CommitTSBuffer</literal>.  Change the code to match the
      documentation, as that way is more consistent with the naming of
      related wait events.
     </para>
    </listitem>

    <listitem>
<!--
Author: Nathan Bossart <nathan@postgresql.org>
Branch: master [b72623671] 2023-04-27 14:31:17 -0700
Branch: REL_15_STABLE [c98b06e2f] 2023-04-27 14:31:33 -0700
Branch: REL_14_STABLE [137003036] 2023-04-27 14:32:40 -0700
Branch: REL_13_STABLE [be40dd63e] 2023-04-27 14:32:55 -0700
-->
     <para>
      Avoid possible underflow when calculating how many WAL segments to
      keep (Kyotaro Horiguchi)
     </para>

     <para>
      This could result in not honoring <varname>wal_keep_size</varname>
      accurately.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [9244c11af] 2023-02-15 10:12:16 +0900
Branch: REL_15_STABLE [5fd61055e] 2023-02-15 10:12:31 +0900
Branch: REL_14_STABLE [864f80fea] 2023-02-15 10:12:33 +0900
Branch: REL_13_STABLE [2eb8e54cc] 2023-02-15 10:12:36 +0900
Branch: REL_12_STABLE [a40e7b75e] 2023-02-15 10:12:38 +0900
Branch: REL_11_STABLE [88d606f7c] 2023-02-15 10:12:40 +0900
-->
     <para>
      Support RSA-PSS certificates with SCRAM-SHA-256 channel binding
      (Jacob Champion, Heikki Linnakangas)
     </para>

     <para>
      This feature requires building with OpenSSL 1.1.1 or newer.  Both
      the server and <application>libpq</application> are affected.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [d41a178b3] 2023-03-15 13:24:47 +1300
Branch: REL_15_STABLE [06066915d] 2023-03-15 13:25:56 +1300
Branch: REL_14_STABLE [9b6e0b9c3] 2023-03-15 13:30:58 +1300
Branch: REL_13_STABLE [9f1c64018] 2023-03-15 13:31:34 +1300
Branch: REL_12_STABLE [836288427] 2023-03-15 13:32:21 +1300
Branch: REL_11_STABLE [5ff8e69d8] 2023-03-15 13:32:41 +1300
Branch: master [6a9229da6] 2023-03-17 10:44:46 +1300
Branch: REL_15_STABLE [75e7378f6] 2023-03-17 10:45:20 +1300
Branch: REL_14_STABLE [00fc4b3a3] 2023-03-17 09:52:45 +1300
Branch: REL_13_STABLE [798dae9f6] 2023-03-17 09:54:03 +1300
Branch: REL_12_STABLE [6f508b8bc] 2023-03-17 09:54:51 +1300
Branch: REL_11_STABLE [9d6c34397] 2023-03-17 09:58:08 +1300
Branch: master [10b6745d3] 2023-03-17 14:44:12 +1300
Branch: REL_15_STABLE [e8a774d00] 2023-03-17 14:46:03 +1300
Branch: REL_14_STABLE [1c0d4affa] 2023-03-17 14:46:50 +1300
Branch: REL_13_STABLE [77a8133c9] 2023-03-17 14:47:16 +1300
Branch: REL_12_STABLE [8fcd1517f] 2023-03-17 14:47:38 +1300
Branch: REL_11_STABLE [b23f2a729] 2023-03-17 14:48:08 +1300
-->
     <para>
      Avoid race condition with process ID tracking on Windows (Thomas Munro)
     </para>

     <para>
      The operating system could recycle a PID before the postmaster
      observed that that child process was gone.  This could lead to
      tracking more than one child with the same PID, resulting in
      confusion.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [d0460a31d] 2023-02-22 13:23:09 +0000
Branch: REL_15_STABLE [576b25bfd] 2023-02-22 13:24:51 +0000
Branch: REL_14_STABLE [482ab3e4f] 2023-02-22 13:26:20 +0000
Branch: REL_13_STABLE [906356cf6] 2023-02-22 13:27:29 +0000
Branch: REL_12_STABLE [52dbd9f84] 2023-02-22 13:28:30 +0000
Branch: REL_11_STABLE [83a54d966] 2023-02-22 13:29:39 +0000
-->
     <para>
      Add missing cases to <function>SPI_result_code_string()</function>
      (Dean Rasheed)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b3e184a5d] 2023-02-21 18:48:15 -0500
Branch: REL_15_STABLE [f6a55c1d5] 2023-02-21 18:47:46 -0500
Branch: REL_14_STABLE [dc44180f6] 2023-02-21 18:47:47 -0500
Branch: REL_13_STABLE [99e74cd23] 2023-02-21 18:47:47 -0500
Branch: REL_12_STABLE [463bef383] 2023-02-21 18:47:47 -0500
Branch: REL_11_STABLE [21bd818d0] 2023-02-21 18:47:47 -0500
-->
     <para>
      Fix erroneous Valgrind markings
      in <function>AllocSetRealloc()</function> (Karina Litskevich)
     </para>

     <para>
      In the unusual case where the size of a large (&gt;8kB) palloc chunk
      is decreased, a Valgrind-aware build would mismark the defined-ness
      state of the memory released from the chunk, possibly causing
      incorrect results during Valgrind testing.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [7fe1aa991] 2023-02-22 15:24:18 +0100
Branch: REL_15_STABLE [949ac32e1] 2023-02-22 16:48:30 +0100
Branch: REL_14_STABLE [8b9cbd42b] 2023-02-22 16:25:45 +0100
Branch: REL_13_STABLE [4df581fa0] 2023-02-22 16:09:30 +0100
Branch: REL_12_STABLE [497f863f0] 2023-02-22 15:50:37 +0100
Branch: REL_11_STABLE [8de91ebf2] 2023-02-22 15:35:19 +0100
-->
     <para>
      Avoid assertion failure when decoding a transactional logical
      replication message (Tomas Vondra)
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [c04c6c5d6] 2023-04-21 08:19:41 -0700
Branch: REL_15_STABLE [109363de0] 2023-04-21 08:20:17 -0700
Branch: REL_14_STABLE [dde926b0f] 2023-04-21 08:20:32 -0700
Branch: REL_13_STABLE [79a66c617] 2023-04-21 08:20:47 -0700
Branch: REL_12_STABLE [5bcb15b81] 2023-04-21 08:21:04 -0700
Branch: REL_11_STABLE [106a1bf82] 2023-04-21 08:21:18 -0700
-->
     <para>
      Avoid locale sensitivity when processing regular expression escapes
      (Jeff Davis)
     </para>

     <para>
      A backslash followed by a non-ASCII character could sometimes cause
      an assertion failure, depending on the prevailing locale.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3e383f9b6] 2023-04-17 14:22:26 -0400
Branch: REL_15_STABLE [2207df7c3] 2023-04-17 14:22:06 -0400
Branch: REL_14_STABLE [72a914e9f] 2023-04-17 14:22:06 -0400
Branch: REL_13_STABLE [86874a6df] 2023-04-17 14:22:06 -0400
Branch: REL_12_STABLE [9b0c1f213] 2023-04-17 14:22:06 -0400
Branch: REL_11_STABLE [c796d7296] 2023-04-17 14:22:06 -0400
-->
     <para>
      Avoid trying to write an empty WAL record
      in <function>log_newpage_range()</function> when the last few pages
      in the specified range are empty (Matthias van de Meent)
     </para>

     <para>
      It is not entirely clear whether this case is reachable in released
      branches, but if it is then an assertion failure could occur.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [441ee1677] 2023-04-24 14:19:46 -0400
Branch: REL_15_STABLE [c1598d85f] 2023-04-24 14:19:46 -0400
Branch: REL_14_STABLE [2ba890ce7] 2023-04-24 14:19:46 -0400
Branch: REL_13_STABLE [bfa691087] 2023-04-24 14:19:46 -0400
Branch: REL_12_STABLE [ee71cad9a] 2023-04-24 14:19:46 -0400
-->
     <para>
      Fix session-lifespan memory leakage in <application>plpgsql</application>
      <literal>DO</literal> blocks that use cast expressions
      (Ajit Awekar, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f47004add] 2023-04-29 13:06:44 -0400
Branch: REL_15_STABLE [ce9a1a3ea] 2023-04-29 13:06:44 -0400
Branch: REL_14_STABLE [1e868bb6c] 2023-04-29 13:06:44 -0400
Branch: REL_13_STABLE [ee24b5e79] 2023-04-29 13:06:44 -0400
Branch: REL_12_STABLE [900a8d526] 2023-04-29 13:06:44 -0400
Branch: REL_11_STABLE [ea96fbe77] 2023-04-29 13:06:44 -0400
-->
     <para>
      Tighten array dimensionality checks when converting Perl
      list structures to multi-dimensional SQL arrays (Tom Lane)
     </para>

     <para>
      <application>plperl</application> could misbehave when the nesting
      of sub-lists is inconsistent so that the data does not represent a
      rectangular array of values.  Such cases now produce errors, but
      previously they could result in a crash or garbage output.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0553528e7] 2023-05-04 11:00:33 -0400
Branch: REL_15_STABLE [b7001c6b6] 2023-05-04 11:00:33 -0400
Branch: REL_14_STABLE [9d517339e] 2023-05-04 11:00:33 -0400
Branch: REL_13_STABLE [0e6354ed9] 2023-05-04 11:00:33 -0400
Branch: REL_12_STABLE [b7fcf3824] 2023-05-04 11:00:33 -0400
Branch: REL_11_STABLE [aa7e5e404] 2023-05-04 11:00:33 -0400
Branch: master [81eaaf65e] 2023-04-28 12:24:29 -0400
Branch: REL_15_STABLE [512c55522] 2023-04-28 12:24:29 -0400
Branch: REL_14_STABLE [a1d9aacc4] 2023-04-28 12:24:29 -0400
Branch: REL_13_STABLE [7dcd9998c] 2023-04-28 12:24:29 -0400
Branch: REL_12_STABLE [ff9203f46] 2023-04-28 12:24:29 -0400
Branch: REL_11_STABLE [b7c6af375] 2023-04-28 12:24:29 -0400
-->
     <para>
      Tighten array dimensionality checks when converting Python
      list structures to multi-dimensional SQL arrays (Tom Lane)
     </para>

     <para>
      <application>plpython</application> could misbehave when dealing
      with empty sub-lists, or when the nesting of sub-lists is
      inconsistent so that the data does not represent a rectangular array
      of values.  The former should result in an empty output array, and
      the latter in an error.  But some cases resulted in a crash, and
      others in unexpected output.
     </para>
    </listitem>

    <listitem>
<!--
Author: Nathan Bossart <nathan@postgresql.org>
Branch: master [57d005170] 2023-05-04 16:23:05 -0700
Branch: REL_15_STABLE [825ebc984] 2023-05-04 16:24:48 -0700
Branch: REL_14_STABLE [52c9cf323] 2023-05-04 16:25:05 -0700
Branch: REL_13_STABLE [800531846] 2023-05-04 16:26:00 -0700
Branch: REL_12_STABLE [24964394a] 2023-05-04 16:26:05 -0700
Branch: REL_11_STABLE [0af386b0f] 2023-05-04 16:26:11 -0700
-->
     <para>
      Fix unwinding of exception stack
      in <application>plpython</application> (Xing Guo)
     </para>

     <para>
      Some rare failure cases could return without cleaning up the PG_TRY
      exception stack, risking a crash if another error was raised before
      the next stack level was unwound.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [e0a09d4e3] 2023-03-13 16:36:20 +0900
Branch: REL_15_STABLE [4493256c5] 2023-03-13 16:36:28 +0900
Branch: REL_14_STABLE [7e319231c] 2023-03-13 16:36:31 +0900
Branch: REL_13_STABLE [96bef4374] 2023-03-13 16:36:33 +0900
Branch: REL_12_STABLE [2bc36a56c] 2023-03-13 16:36:34 +0900
-->
     <para>
      Fix inconsistent GSS-encryption error handling
      in <application>libpq</application>'s
      <function>PQconnectPoll()</function>
      (Michael Paquier)
     </para>

     <para>
      With <option>gssencmode</option> set to <literal>require</literal>,
      the connection was not marked dead after a GSS initialization
      failure.  Make it fail immediately, as the equivalent case for TLS
      encryption has long done.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [f18029084] 2023-04-18 11:20:41 +0900
Branch: REL_15_STABLE [8c746be44] 2023-04-18 11:20:47 +0900
Branch: REL_14_STABLE [02f076454] 2023-04-18 11:20:50 +0900
Branch: REL_13_STABLE [e9e457d22] 2023-04-18 11:20:51 +0900
Branch: REL_12_STABLE [a28bd7713] 2023-04-18 11:20:53 +0900
Branch: REL_11_STABLE [9eb44bb04] 2023-04-18 11:20:55 +0900
Branch: REL_11_STABLE [dbd25dd0b] 2023-04-18 12:00:31 +0900
-->
     <para>
      Fix possible data corruption in <application>ecpg</application>
      programs built with the <option>-C ORACLE</option> option
      (Kyotaro Horiguchi)
     </para>

     <para>
      When <function>ecpg_get_data()</function> is called
      with <varname>varcharsize</varname> set to zero, it could write a
      terminating zero character into the last byte of the preceding
      field, truncating the data in that field.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [bc8cd50fe] 2023-03-17 13:31:40 -0400
Branch: REL_15_STABLE [2b216da1e] 2023-03-17 13:31:40 -0400
Branch: REL_14_STABLE [5fc1ac151] 2023-03-17 13:31:40 -0400
Branch: REL_13_STABLE [7e7c5b683] 2023-03-17 13:31:40 -0400
Branch: REL_12_STABLE [8f83ce8c5] 2023-03-17 13:31:40 -0400
Branch: REL_11_STABLE [012ffb365] 2023-03-17 13:31:40 -0400
-->
     <para>
      Fix <application>pg_dump</application> so that partitioned tables
      that are hash-partitioned on an enum-type column can be restored
      successfully (Tom Lane)
     </para>

     <para>
      Since the hash codes for enum values depend on the OIDs assigned to
      the enum, they are typically different after a dump and restore,
      meaning that rows often need to go into a different partition than
      they were in originally.  Users can work around that by specifying
      the <option>--load-via-partition-root</option> option; but since
      there is very little chance of success without that,
      teach <application>pg_dump</application> to apply it automatically
      to such tables.
     </para>

     <para>
      Also, fix <application>pg_restore</application> to not try
      to <command>TRUNCATE</command> target tables before restoring into
      them when <option>--load-via-partition-root</option> mode is used.
      This avoids a hazard of deadlocks and lost data.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [df38157d9] 2023-04-27 11:55:06 -0400
Branch: REL_15_STABLE [85ec8bcce] 2023-04-27 11:55:06 -0400
Branch: REL_14_STABLE [c74f88c40] 2023-04-27 11:55:06 -0400
Branch: REL_13_STABLE [de2dfa053] 2023-04-27 11:55:06 -0400
Branch: REL_12_STABLE [ce9662598] 2023-04-27 11:55:06 -0400
Branch: REL_11_STABLE [c3c1097dc] 2023-04-27 11:55:06 -0400
-->
     <para>
      In <filename>contrib/hstore_plpython</filename>, avoid crashing if
      the Python value to be transformed isn't a mapping (Dmitry Dolgov,
      Tom Lane)
     </para>

     <para>
      This should give an error, but Python 3 changed some APIs in a way
      that caused the check to misbehave, allowing a crash to ensue.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [8bbd0cce9] 2023-04-23 14:30:09 +0300
Branch: REL_15_STABLE [214495dc5] 2023-04-23 14:30:51 +0300
Branch: REL_14_STABLE [f4a4a18ec] 2023-04-23 14:31:11 +0300
Branch: REL_13_STABLE [48c6825d0] 2023-04-23 14:00:16 +0300
-->
     <para>
      Require the <literal>siglen</literal> option of a GiST index on
      an <type>ltree</type> column, if specified, to be a multiple of 4
      (Alexander Korotkov)
     </para>

     <para>
      Other values result in misaligned accesses to index content, which
      is harmless on Intel-compatible hardware but can cause a crash on
      some other architectures.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1925ac281] 2023-03-11 12:15:41 -0500
Branch: REL_15_STABLE [6170386c7] 2023-03-11 12:15:41 -0500
Branch: REL_14_STABLE [786528039] 2023-03-11 12:15:41 -0500
Branch: REL_13_STABLE [bc436e4a9] 2023-03-11 12:15:41 -0500
Branch: REL_12_STABLE [1279414bc] 2023-03-11 12:15:41 -0500
Branch: REL_11_STABLE [b18327489] 2023-03-11 12:15:41 -0500
-->
     <para>
      Fix misbehavior in <filename>contrib/pg_trgm</filename> with an
      unsatisfiable regular expression (Tom Lane)
     </para>

     <para>
      A regex such as <literal>$foo</literal> is legal but unsatisfiable;
      the regex compiler recognizes that and produces an empty NFA graph.
      Attempting to optimize such a graph into a pg_trgm GIN or GiST index
      qualification resulted in accessing off the end of a work array,
      possibly leading to crashes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [eab2d3147] 2023-04-20 18:12:32 -0400
Branch: REL_15_STABLE [a14afd3bd] 2023-04-20 18:12:48 -0400
Branch: REL_14_STABLE [6d60b718c] 2023-04-20 18:12:32 -0400
Branch: REL_13_STABLE [6dce37203] 2023-04-20 18:12:32 -0400
Branch: REL_12_STABLE [e2e34dfff] 2023-04-20 18:12:32 -0400
Branch: REL_11_STABLE [c976ccc9e] 2023-04-20 18:12:32 -0400
-->
     <para>
      Use the <option>--strip-unneeded</option> option when stripping
      static libraries with
      GNU-compatible <application>strip</application> (Tom Lane)
     </para>

     <para>
      Previously, <literal>make install-strip</literal> used
      the <option>-x</option> option in this case.  This change avoids
      misbehavior of <application>llvm-strip</application>, and gives
      slightly smaller output as well.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [969509c3f] 2023-02-08 17:15:25 -0500
Branch: REL_15_STABLE [2ee703c9d] 2023-02-08 17:15:23 -0500
Branch: REL_14_STABLE [7f8778fcf] 2023-02-08 17:15:23 -0500
Branch: REL_13_STABLE [c7b608600] 2023-02-08 17:15:23 -0500
Branch: REL_12_STABLE [11f1f9f4f] 2023-02-08 17:15:27 -0500
Branch: REL_11_STABLE [36a646d99] 2023-02-08 17:15:27 -0500
-->
     <para>
      Stop recommending auto-download of DTD files for building the
      documentation, and indeed disable it (Aleksander Alekseev, Peter
      Eisentraut, Tom Lane)
     </para>

     <para>
      It appears no longer possible to build the SGML documentation
      without a local installation of the DocBook DTD files.
      Formerly <application>xsltproc</application> could download those
      files on-the-fly from sourceforge.net; but sourceforge.net now
      permits only HTTPS access, and no common version
      of <application>xsltproc</application> supports that.  Hence, remove
      the bits of our documentation suggesting that that's possible or
      useful, and instead
      add <application>xsltproc</application>'s <option>--nonet</option>
      option to the build recipes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [5d42a9751] 2023-05-05 07:09:52 +0200
Branch: REL_15_STABLE [3d37476f5] 2023-05-05 07:10:15 +0200
Branch: REL_14_STABLE [e07022500] 2023-05-05 07:10:30 +0200
Branch: REL_13_STABLE [670494477] 2023-05-05 07:11:58 +0200
Branch: REL_12_STABLE [14bb2e76c] 2023-05-05 07:12:18 +0200
Branch: REL_11_STABLE [b189f71e5] 2023-05-05 07:12:26 +0200
-->
     <para>
      When running TAP tests in PGXS builds, use a saner location for the
      temporary <filename>portlock</filename> directory (Peter Eisentraut)
     </para>

     <para>
      Place it under <filename>tmp_check</filename> in the build
      directory.  With the previous coding, a PGXS build would try to place
      it in the installation directory, which is not necessarily writable.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4ddee4d9d] 2023-04-18 14:46:39 -0400
Branch: REL_15_STABLE [62b22caa5] 2023-04-18 14:46:39 -0400
Branch: REL_14_STABLE [b79b36f26] 2023-04-18 14:46:39 -0400
Branch: REL_13_STABLE [87d8ec3e4] 2023-04-18 14:46:39 -0400
Branch: REL_12_STABLE [2ad35cf06] 2023-04-18 14:46:39 -0400
Branch: REL_11_STABLE [7228f2f81] 2023-04-18 14:46:39 -0400
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2023c for DST law changes in Egypt, Greenland, Morocco, and
      Palestine.
     </para>

     <para>
      When observing Moscow time, Europe/Kirov and Europe/Volgograd now
      use the abbreviations MSK/MSD instead of numeric abbreviations,
      for consistency with other timezones observing Moscow time.
      Also, America/Yellowknife is no longer distinct from America/Edmonton;
      this affects some pre-1948 timestamps in that area.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-10">
  <title>Release 13.10</title>

  <formalpara>
  <title>Release date:</title>
  <para>2023-02-09</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.9.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.10</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you are upgrading from a version earlier than 13.7,
    see <xref linkend="release-13-7"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [71c37797d] 2023-02-06 11:20:07 +0900
Branch: REL_15_STABLE [715c345dd] 2023-02-06 11:20:20 +0900
Branch: REL_14_STABLE [626f2c1d6] 2023-02-06 11:20:23 +0900
Branch: REL_13_STABLE [45a945ee9] 2023-02-06 11:20:27 +0900
Branch: REL_12_STABLE [3f7342671] 2023-02-06 11:20:31 +0900
-->
     <para>
      <application>libpq</application> can leak memory contents after
      GSSAPI transport encryption initiation fails (Jacob Champion)
     </para>

     <para>
      A modified server, or an unauthenticated man-in-the-middle, can
      send a not-zero-terminated error message during setup of GSSAPI
      (Kerberos) transport encryption.  <application>libpq</application>
      will then copy that string, as well as following bytes in
      application memory up to the next zero byte, to its error report.
      Depending on what the calling application does with the error
      report, this could result in disclosure of application memory
      contents.  There is also a small probability of a crash due to
      reading beyond the end of memory.  Fix by properly zero-terminating
      the server message.
      (CVE-2022-41862)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3f7836ff6] 2023-01-05 14:12:17 -0500
Branch: REL_15_STABLE [3706cc97a] 2023-01-05 14:12:17 -0500
Branch: REL_14_STABLE [8cd190e13] 2023-01-05 14:12:17 -0500
Branch: REL_13_STABLE [ad38e2f89] 2023-01-05 14:12:17 -0500
Branch: master [3f244d020] 2023-01-15 13:14:52 -0500
Branch: REL_15_STABLE [a8f7687a0] 2023-01-15 14:06:46 -0500
Branch: REL_14_STABLE [a8b88c26f] 2023-01-15 14:06:46 -0500
Branch: REL_13_STABLE [787db4be9] 2023-01-15 14:06:46 -0500
-->
     <para>
      Fix calculation of which <literal>GENERATED</literal> columns need
      to be updated in child tables during an <command>UPDATE</command> on
      a partitioned table or inheritance tree (Amit Langote, Tom Lane)
     </para>

     <para>
      This fixes failure to update <literal>GENERATED</literal> columns
      that do not exist in the parent table, or that have different
      dependencies than are in the parent column's generation expression.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c9f7f9264] 2023-01-21 13:10:29 -0500
Branch: REL_15_STABLE [9e4288ce6] 2023-01-21 13:10:29 -0500
Branch: REL_14_STABLE [70ec756b0] 2023-01-21 13:10:29 -0500
Branch: REL_13_STABLE [72d611109] 2023-01-21 13:10:29 -0500
Branch: REL_12_STABLE [a5f3f2fce] 2023-01-21 13:10:30 -0500
Branch: REL_11_STABLE [6c122edde] 2023-01-21 13:10:30 -0500
-->
     <para>
      Allow <literal>REPLICA IDENTITY</literal>
      to be set on an index that's not (yet) valid (Tom Lane)
     </para>

     <para>
      When <application>pg_dump</application> dumps a partitioned index
      that's marked <literal>REPLICA IDENTITY</literal>, it generates a
      command sequence that applies <literal>REPLICA IDENTITY</literal>
      before the partitioned index has been marked valid, causing restore
      to fail.  There seems no very good reason to prohibit doing it in
      that order, so allow it.  The marking will have no effect anyway
      until the index becomes valid.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [2605643a3] 2022-12-03 12:11:33 +0000
Branch: REL_15_STABLE [c67204db6] 2022-12-03 12:14:36 +0000
Branch: REL_14_STABLE [2c7ed9f75] 2022-12-03 12:16:07 +0000
Branch: REL_13_STABLE [3bed88123] 2022-12-03 12:17:47 +0000
Branch: REL_12_STABLE [33f600f04] 2022-12-03 12:18:58 +0000
Branch: REL_11_STABLE [30f9b03a0] 2022-12-03 12:20:02 +0000
-->
     <para>
      Fix handling of <literal>DEFAULT</literal> markers in rules that
      perform an <command>INSERT</command> from a
      multi-row <literal>VALUES</literal> list (Dean Rasheed)
     </para>

     <para>
      In some cases a <literal>DEFAULT</literal> marker would not get
      replaced with the proper default-value expression, leading to
      an <quote>unrecognized node type</quote> error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [3161ae86c] 2023-01-12 18:16:34 +0300
Branch: REL_15_STABLE [4dc3f94fa] 2023-01-12 18:17:43 +0300
Branch: REL_14_STABLE [0d9221f1d] 2023-01-12 18:18:04 +0300
Branch: REL_13_STABLE [2ff3ac3b5] 2023-01-12 18:18:31 +0300
Branch: REL_12_STABLE [9e24e4781] 2023-01-12 18:19:19 +0300
-->
     <para>
      Reject uses of undefined variables in <type>jsonpath</type>
      existence checks (Alexander Korotkov, David G. Johnston)
     </para>

     <para>
      While <type>jsonpath</type> match operators threw an error for an
      undefined variable in the path pattern, the existence operators
      silently treated it as a match.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [ffcf6f4cf] 2023-01-26 14:52:19 +1300
Branch: REL_15_STABLE [d9f5345bf] 2023-01-26 14:53:37 +1300
Branch: REL_14_STABLE [2f65b8468] 2023-01-26 14:54:17 +1300
Branch: REL_13_STABLE [1a5afe007] 2023-01-26 14:54:39 +1300
Branch: REL_12_STABLE [b55303792] 2023-01-26 14:55:03 +1300
Branch: REL_11_STABLE [d95dcc9ab] 2023-01-26 14:55:37 +1300
-->
     <para>
      Fix edge-case data corruption in parallel hash joins (Dmitry Astapov)
     </para>

     <para>
      If the final chunk of a large tuple being written out to a temporary
      file was exactly 32760 bytes, it would be corrupted due to a
      fencepost bug.  The query would typically fail later with
      corrupted-data symptoms.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [7e8a80d1f] 2023-01-19 13:13:05 +0900
Branch: REL_15_STABLE [49e3a5e71] 2023-01-19 13:13:27 +0900
Branch: REL_14_STABLE [2e21e2857] 2023-01-19 13:13:28 +0900
Branch: REL_13_STABLE [fed4e92f3] 2023-01-19 13:13:30 +0900
Branch: REL_12_STABLE [162a48287] 2023-01-19 13:13:32 +0900
Branch: REL_11_STABLE [0c2f34af7] 2023-01-19 13:13:34 +0900
-->
     <para>
      Honor non-default settings
      of <varname>checkpoint_completion_target</varname>
      (Bharath Rupireddy)
     </para>

     <para>
      Internal state was not updated after a change
      in <varname>checkpoint_completion_target</varname>, possibly
      resulting in performing checkpoint I/O faster or slower than
      desired, especially if that setting was changed on-the-fly.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [44e9e3426] 2023-01-19 12:23:20 -0500
Branch: REL_15_STABLE [abe203304] 2023-01-19 12:23:20 -0500
Branch: REL_14_STABLE [103450724] 2023-01-19 12:23:20 -0500
Branch: REL_13_STABLE [1b9a0b96a] 2023-01-19 12:23:20 -0500
Branch: REL_12_STABLE [87591db19] 2023-01-19 12:23:20 -0500
Branch: REL_11_STABLE [0a269527f] 2023-01-19 12:23:20 -0500
-->
     <para>
      Log the correct ending timestamp
      in <varname>recovery_target_xid</varname> mode (Tom Lane)
     </para>

     <para>
      When ending recovery based on the <varname>recovery_target_xid</varname>
      setting with <varname>recovery_target_inclusive</varname>
      = <literal>off</literal>, we printed an incorrect timestamp (always
      2000-01-01) in the <quote>recovery stopping before
      ... transaction</quote> log message.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [1561612e3] 2023-01-16 09:44:04 +0100
Branch: REL_15_STABLE [ac01fa647] 2023-01-16 09:45:03 +0100
Branch: REL_14_STABLE [f463335e1] 2023-01-16 09:48:09 +0100
Branch: REL_13_STABLE [cf74b6ead] 2023-01-16 09:54:15 +0100
-->
     <para>
      Improve error reporting for some buffered file read failures
      (Peter Eisentraut)
     </para>

     <para>
      Correctly report a short read, giving the numbers of bytes desired
      and actually read, instead of reporting an irrelevant error code.
      Most places got this right already, but some recently-written
      replication logic did not.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_13_STABLE [72b6098be] 2023-01-11 09:56:14 +0900
Branch: REL_12_STABLE [c0ee6943c] 2023-01-11 09:56:18 +0900
-->
     <para>
      Prevent <quote>wrong tuple length</quote> failure
      at the end of <command>VACUUM</command> (Ashwin Agrawal, Junfeng Yang)
     </para>

     <para>
      This occurred if <command>VACUUM</command> needed to update the
      current database's <structfield>datfrozenxid</structfield> value and
      the database has so many granted privileges that
      its <structfield>datacl</structfield> value has been pushed
      out-of-line.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [20432f873] 2022-12-13 14:23:58 -0500
Branch: REL_15_STABLE [18431ee6f] 2022-12-13 14:23:59 -0500
Branch: REL_14_STABLE [ae47f8a96] 2022-12-13 14:23:59 -0500
Branch: REL_13_STABLE [942cc240f] 2022-12-13 14:23:59 -0500
Branch: REL_12_STABLE [1cca4a75f] 2022-12-13 14:23:59 -0500
Branch: REL_11_STABLE [f48aa5df4] 2022-12-13 14:23:59 -0500
-->
     <para>
      In extended query protocol, avoid an immediate commit
      after <command>ANALYZE</command> if we're running a pipeline
      (Tom Lane)
     </para>

     <para>
      If there's not been an explicit <command>BEGIN
      TRANSACTION</command>, <command>ANALYZE</command> would take it on
      itself to commit, which should not happen within a pipelined series
      of commands.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [e52daaabf] 2023-01-21 06:08:00 -0800
Branch: REL_15_STABLE [b152bb7b2] 2023-01-21 06:08:03 -0800
Branch: REL_14_STABLE [6900aea67] 2023-01-21 06:08:04 -0800
Branch: REL_13_STABLE [a9bccffe5] 2023-01-21 06:08:04 -0800
Branch: REL_12_STABLE [e75b5c855] 2023-01-21 06:08:04 -0800
Branch: REL_11_STABLE [8f70de7e0] 2023-01-21 06:08:05 -0800
-->
     <para>
      Reject cancel request packets having the wrong length
      (Andrey Borodin)
     </para>

     <para>
      The server would process a cancel request even if its length word
      was too small.  This led to reading beyond the end of the allocated
      buffer.  In theory that could cause a segfault, but it seems quite
      unlikely to happen in practice, since the buffer would have to be
      very close to the end of memory.  The more likely outcome was a bogus
      log message about wrong backend PID or cancel code.  Complain about
      the wrong length, instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5beb7881f] 2022-12-22 10:35:02 -0500
Branch: REL_15_STABLE [1a3daa5bb] 2022-12-22 10:35:02 -0500
Branch: REL_14_STABLE [97431d673] 2022-12-22 10:35:02 -0500
Branch: REL_13_STABLE [4fceb454f] 2022-12-22 10:35:03 -0500
Branch: REL_12_STABLE [d572003f7] 2022-12-22 10:35:03 -0500
Branch: REL_11_STABLE [8cd700cc5] 2022-12-22 10:35:03 -0500
-->
     <para>
      Add recursion and looping defenses in subquery pullup (Tom Lane)
     </para>

     <para>
      A contrived query can result in deep recursion and unreasonable
      amounts of time spent trying to flatten subqueries.  A proper fix
      for that seems unduly invasive for a back-patch, but we can at least
      add stack depth checks and an interrupt check to allow the query to
      be cancelled.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [fe12f2f8f] 2022-12-04 13:17:18 -0500
Branch: REL_15_STABLE [bf8fd64ff] 2022-12-04 13:17:18 -0500
Branch: REL_14_STABLE [ec3daeec3] 2022-12-04 13:17:18 -0500
Branch: REL_13_STABLE [4ebca555c] 2022-12-04 13:17:18 -0500
Branch: REL_12_STABLE [1ff549e84] 2022-12-04 13:17:18 -0500
Branch: REL_11_STABLE [2df073313] 2022-12-04 13:17:18 -0500
-->
     <para>
      Fix partitionwise-join code to tolerate failure to produce a plan for
      each partition (Tom Lane)
     </para>

     <para>
      This could result in <quote>could not devise a query plan for the
      given query</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9c6ad5eaa] 2022-11-22 14:40:20 -0500
Branch: REL_15_STABLE [2debceed2] 2022-11-22 14:40:44 -0500
Branch: REL_14_STABLE [bd06fe4de] 2022-11-22 14:40:45 -0500
Branch: REL_13_STABLE [6e639267a] 2022-11-22 14:40:45 -0500
Branch: REL_12_STABLE [ec10b6139] 2022-11-22 14:40:45 -0500
Branch: REL_11_STABLE [b96a096db] 2022-11-22 14:40:46 -0500
-->
     <para>
      Limit the amount of cleanup work done
      by <function>get_actual_variable_range</function> (Simon Riggs)
     </para>

     <para>
      Planner runs occurring just after deletion of a large number of
      tuples appearing at the end of an index could expend significant
      amounts of work setting the <quote>killed</quote> bits for those
      index entries.  Limit the amount of work done in any one query by
      giving up on this process after examining 100 heap pages.  All the
      cleanup will still happen eventually, but without so large a
      performance hiccup.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5644d6f90] 2022-11-21 17:07:29 -0500
Branch: REL_15_STABLE [0353db996] 2022-11-21 17:07:07 -0500
Branch: REL_14_STABLE [1b9c04b13] 2022-11-21 17:07:07 -0500
Branch: REL_13_STABLE [74670688f] 2022-11-21 17:07:07 -0500
Branch: REL_12_STABLE [1aed4c4fd] 2022-11-21 17:07:07 -0500
Branch: REL_11_STABLE [c0eed8891] 2022-11-21 17:07:07 -0500
-->
     <para>
      Ensure that execution of full-text-search queries can be cancelled
      while they are performing phrase matches (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [edf12e7bb] 2022-12-01 11:49:15 -0800
Branch: REL_15_STABLE [9377b4f30] 2022-12-01 11:55:59 -0800
Branch: REL_14_STABLE [47e1224d5] 2022-12-01 11:53:53 -0800
Branch: REL_13_STABLE [a844052b5] 2022-12-01 11:52:06 -0800
Branch: REL_12_STABLE [f98c4fb1d] 2022-12-01 11:49:43 -0800
-->
     <para>
      Fix memory leak in hashing strings with nondeterministic collations
      (Jeff Davis)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [bc54ef4ec] 2023-01-23 18:27:42 -0800
Branch: REL_15_STABLE [704a330a9] 2023-01-23 18:27:45 -0800
Branch: REL_14_STABLE [0a796b8b3] 2023-01-23 18:27:48 -0800
Branch: REL_13_STABLE [c5864805b] 2023-01-23 18:27:51 -0800
Branch: REL_12_STABLE [92fc12787] 2023-01-23 18:27:55 -0800
Branch: REL_11_STABLE [243373159] 2023-01-23 18:27:58 -0800
-->
     <para>
      Clean up the <application>libpq</application> connection object
      after a failed replication connection attempt (Andres Freund)
     </para>

     <para>
      The previous coding leaked the connection object.  In background
      code paths that's pretty harmless because the calling process will
      give up and exit.  But in commands such as <command>CREATE
      SUBSCRIPTION</command>, such a failure resulted in a small
      session-lifespan memory leak.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8242752f9] 2022-11-29 15:43:17 -0500
Branch: REL_15_STABLE [55fa993d7] 2022-11-29 15:43:17 -0500
Branch: REL_14_STABLE [06998eab1] 2022-11-29 15:43:17 -0500
Branch: REL_13_STABLE [6e8ad1152] 2022-11-29 15:43:17 -0500
Branch: REL_12_STABLE [c4a153d77] 2022-11-29 15:43:17 -0500
Branch: REL_11_STABLE [a6c9e1db2] 2022-11-29 15:43:17 -0500
-->
     <para>
      In hot-standby servers, reduce processing effort for tracking XIDs
      known to be active on the primary (Simon Riggs, Michail Nikolaev)
     </para>

     <para>
      Insufficiently-aggressive cleanup of the KnownAssignedXids array
      could lead to poor performance, particularly
      when <varname>max_connections</varname> is set to a large value on
      the standby.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [0557e1770] 2022-11-22 10:56:07 +0100
Branch: REL_15_STABLE [1ad033df1] 2022-11-22 10:56:07 +0100
Branch: REL_14_STABLE [1b3ed7571] 2022-11-22 10:56:07 +0100
Branch: REL_13_STABLE [36eeb37cd] 2022-11-22 10:56:07 +0100
-->
     <para>
      Ignore invalidated logical-replication slots while determining
      oldest catalog xmin (Sirisha Chamarthi)
     </para>

     <para>
      A replication slot could prevent cleanup of dead tuples in the
      system catalogs even after it becomes invalidated due to
      exceeding <varname>max_slot_wal_keep_size</varname>.  Thus, failure
      of a replication consumer could lead to indefinitely-large catalog
      bloat.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: REL_15_STABLE [898ef41bf] 2022-11-25 09:38:03 +0530
Branch: REL_14_STABLE [9f2cc1a73] 2022-11-25 09:25:50 +0530
Branch: REL_13_STABLE [4ec157c15] 2022-11-25 09:15:31 +0530
Branch: REL_12_STABLE [aa9d916f6] 2022-11-25 09:00:15 +0530
Branch: REL_11_STABLE [9b788aafd] 2022-11-25 08:56:54 +0530
-->
     <para>
      Fix uninitialized-memory usage in logical decoding (Masahiko Sawada)
     </para>

     <para>
      In certain cases, resumption of logical decoding could try to re-use
      XID data that had already been freed, leading to unpredictable
      behavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [e848be60b] 2022-11-14 10:43:33 +0530
Branch: REL_15_STABLE [e49e19181] 2022-11-14 10:32:47 +0530
Branch: REL_14_STABLE [9693f1900] 2022-11-14 10:22:28 +0530
Branch: REL_13_STABLE [20c223336] 2022-11-14 10:11:10 +0530
Branch: REL_12_STABLE [4dccccb37] 2022-11-14 10:01:14 +0530
Branch: REL_11_STABLE [1703033f8] 2022-11-14 09:52:06 +0530
-->
     <para>
      Avoid rare <quote>failed to acquire cleanup lock</quote> panic
      during WAL replay of hash-index page split operations (Robert Haas)
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [d6a3dbe14] 2022-11-11 12:38:29 -0800
Branch: REL_15_STABLE [7bf713dd2] 2022-11-11 12:46:11 -0800
Branch: REL_14_STABLE [f893af496] 2022-11-11 12:46:22 -0800
Branch: REL_13_STABLE [58a45bb1d] 2022-11-11 12:46:34 -0800
Branch: REL_12_STABLE [7dd39e9e8] 2022-11-11 12:46:44 -0800
Branch: REL_11_STABLE [5eaf3e375] 2022-11-11 12:46:52 -0800
-->
     <para>
      Advance a heap page's LSN when setting its all-visible bit during
      WAL replay (Jeff Davis)
     </para>

     <para>
      Failure to do this left the page possibly different on standby
      servers than the primary, and violated some other expectations about
      when the LSN changes.  This seems only a theoretical hazard so
      far as <productname>PostgreSQL</productname> itself is concerned,
      but it could upset third-party tools.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [32d5a4974] 2022-11-17 16:54:30 -0500
Branch: REL_13_STABLE [9a299cf7c] 2022-11-17 16:54:30 -0500
Branch: REL_12_STABLE [e21856fd6] 2022-11-17 16:54:31 -0500
Branch: REL_11_STABLE [d4acf2eb9] 2022-11-17 16:54:31 -0500
-->
     <para>
      Prevent unsafe usage of a relation cache
      entry's <structfield>rd_smgr</structfield> pointer (Amul Sul)
     </para>

     <para>
      Remove various assumptions that <structfield>rd_smgr</structfield>
      would stay valid over a series of operations, by wrapping all uses
      of it in a function that will recompute it if needed.  This prevents
      bugs occurring when an unexpected cache flush occurs partway through
      such a series.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [f1821b58f] 2023-01-13 11:02:12 +1300
Branch: REL_15_STABLE [8a98523a5] 2023-01-13 11:02:00 +1300
Branch: REL_14_STABLE [547e60b83] 2023-01-13 10:57:29 +1300
Branch: REL_13_STABLE [c159b0383] 2023-01-13 10:54:49 +1300
Branch: REL_12_STABLE [bf388ab82] 2023-01-13 10:54:34 +1300
Branch: REL_11_STABLE [1b40710a8] 2023-01-13 10:54:20 +1300
-->
     <para>
      Fix latent buffer-overrun problem in <literal>WaitEventSet</literal>
      logic (Thomas Munro)
     </para>

     <para>
      The <function>epoll</function>-based
      and <function>kqueue</function>-based implementations could ask the
      kernel for too many events if the size of their internal buffer was
      different from the size of the caller's output buffer.  That case is
      not known to occur in released <productname>PostgreSQL</productname>
      versions, but this error is a hazard for external modules and future
      bug fixes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [8c954168c] 2022-11-19 12:22:04 -0800
Branch: REL_15_STABLE [a0d35ebcc] 2022-11-19 12:33:11 -0800
Branch: REL_14_STABLE [fc4154286] 2022-11-19 12:33:14 -0800
Branch: REL_13_STABLE [c13667b51] 2022-11-19 12:36:33 -0800
Branch: REL_12_STABLE [4cbcb7ed8] 2022-11-19 12:36:48 -0800
Branch: REL_11_STABLE [140c80372] 2022-11-19 12:36:52 -0800
-->
     <para>
      Avoid nominally-undefined behavior when accessing shared memory in
      32-bit builds (Andres Freund)
     </para>

     <para>
      clang's undefined-behavior sanitizer complained about use of a
      pointer that was less aligned than it should be.  It's very unlikely
      that this would cause a problem in non-debug builds, but it's worth
      fixing for testing purposes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [51dfaa0b0] 2022-11-29 10:52:44 -0500
Branch: REL_15_STABLE [556c0b913] 2022-11-29 10:52:44 -0500
Branch: REL_14_STABLE [0224646be] 2022-11-29 10:52:44 -0500
Branch: REL_13_STABLE [aca695fb6] 2022-11-29 10:52:44 -0500
Branch: REL_12_STABLE [bb8d48cb9] 2022-11-29 10:52:44 -0500
-->
     <para>
      Remove faulty assertion in useless-RESULT-RTE optimization logic
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [2fcf685f6] 2022-12-23 10:04:18 +0900
Branch: REL_15_STABLE [e3897a3a4] 2022-12-23 10:04:30 +0900
Branch: REL_14_STABLE [7ad458e06] 2022-12-23 10:04:33 +0900
Branch: REL_13_STABLE [4dbe72d61] 2022-12-23 10:04:34 +0900
Branch: REL_12_STABLE [7445869e1] 2022-12-23 10:04:36 +0900
Branch: REL_11_STABLE [df6fea51f] 2022-12-23 10:04:37 +0900
-->
     <para>
      Fix copy-and-paste errors in cache-lookup-failure messages for ACL
      checks (Justin Pryzby)
     </para>

     <para>
      In principle these errors should never be reached.  But if they are,
      some of them reported the wrong type of object.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [55f30e6c7] 2022-11-19 11:40:30 -0500
Branch: REL_13_STABLE [e46e986ba] 2022-11-19 11:40:30 -0500
Branch: REL_12_STABLE [344b78492] 2022-11-19 11:40:30 -0500
Branch: REL_11_STABLE [b1f106420] 2022-11-19 11:40:30 -0500
Branch: REL_14_STABLE [03ac48549] 2022-11-19 12:00:27 -0500
Branch: REL_13_STABLE [a5b26aaaf] 2022-11-19 12:00:27 -0500
Branch: REL_12_STABLE [1ed6f1b91] 2022-11-19 12:00:27 -0500
Branch: REL_11_STABLE [b7333e826] 2022-11-19 12:00:27 -0500
-->
     <para>
      In <application>pg_dump</application>,
      avoid calling unsafe server functions before we have locks on the
      tables to be examined (Tom Lane, Gilles Darold)
     </para>

     <para>
      <application>pg_dump</application> uses certain server functions
      that can fail if examining a table that gets dropped concurrently.
      Avoid this type of failure by ensuring that we obtain access share
      lock before inquiring too deeply into a table's properties, and that
      we don't apply such functions to tables we don't intend to dump at
      all.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [e7a59094b] 2023-01-06 11:18:44 +0000
Branch: REL_15_STABLE [2daf4664c] 2023-01-06 11:16:53 +0000
Branch: REL_14_STABLE [48599a18d] 2023-01-06 11:15:22 +0000
Branch: REL_13_STABLE [2ad4abedf] 2023-01-06 11:13:34 +0000
Branch: REL_12_STABLE [274185d11] 2023-01-06 11:11:51 +0000
Branch: REL_11_STABLE [c54b88870] 2023-01-06 11:09:56 +0000
-->
     <para>
      Fix tab completion of <command>ALTER
      FUNCTION/PROCEDURE/ROUTINE</command> ... <command>SET
      SCHEMA</command> (Dean Rasheed)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [701c881f7] 2022-12-21 17:51:50 -0500
Branch: REL_15_STABLE [b87037b37] 2022-12-21 17:51:50 -0500
Branch: REL_14_STABLE [f489b480f] 2022-12-21 17:51:50 -0500
Branch: REL_13_STABLE [d35f1d485] 2022-12-21 17:51:50 -0500
Branch: REL_12_STABLE [c8314d62a] 2022-12-21 17:51:50 -0500
Branch: REL_11_STABLE [0ff4056b8] 2022-12-21 17:51:50 -0500
-->
     <para>
      Fix <filename>contrib/seg</filename> to not crash or print garbage
      if an input number has more than 127 digits (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_13_STABLE [c304c069d] 2022-11-09 09:39:53 +0900
Branch: REL_12_STABLE [edb4ef48d] 2022-11-09 09:39:55 +0900
Branch: REL_11_STABLE [91723759e] 2022-11-09 09:39:57 +0900
Branch: REL_10_STABLE [8f5d4ee6c] 2022-11-09 09:39:58 +0900
Branch: REL9_6_STABLE [b2b988110] 2022-11-09 09:40:01 +0900
Branch: REL9_5_STABLE [40064e103] 2022-11-09 09:40:02 +0900
Branch: REL9_4_STABLE [0f5812df6] 2022-11-09 09:40:05 +0900
Branch: REL9_3_STABLE [a5171b880] 2022-11-09 09:40:06 +0900
Branch: REL9_2_STABLE [c58c0770a] 2022-11-09 09:40:09 +0900
-->
     <para>
      In <filename>contrib/sepgsql</filename>, avoid deprecation warnings
      with recent <application>libselinux</application> (Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_15_STABLE [576506303] 2022-11-10 10:23:49 -0500
Branch: REL_14_STABLE [06dca17ad] 2022-11-10 10:23:49 -0500
Branch: REL_13_STABLE [0942acb73] 2022-11-10 10:23:49 -0500
Branch: REL_12_STABLE [cf0f465c0] 2022-11-10 10:23:49 -0500
-->
     <para>
      Fix build on Microsoft Visual Studio 2013 (Tom Lane)
     </para>

     <para>
      A previous patch supposed that all platforms of interest
      have <function>snprintf()</function>, but MSVC 2013 isn't quite
      there yet.  Revert to using <function>sprintf()</function> on that
      platform.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [341f4e002] 2022-11-25 15:28:38 -0500
Branch: REL_15_STABLE [fed54fc9a] 2022-11-25 15:37:33 -0500
Branch: REL_14_STABLE [f76191fd9] 2022-11-25 15:37:33 -0500
Branch: REL_13_STABLE [9fe5cff14] 2022-11-25 15:37:33 -0500
Branch: REL_12_STABLE [171c7fffa] 2022-11-25 15:37:34 -0500
Branch: REL_11_STABLE [ae7c51213] 2022-11-25 15:37:34 -0500
-->
     <para>
      Fix compile failure in building PL/Perl with MSVC when using
      Strawberry Perl (Andrew Dunstan)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [ccc59a83c] 2022-11-27 09:03:22 -0500
Branch: REL_15_STABLE [b5d8fd418] 2022-11-27 09:18:14 -0500
Branch: REL_14_STABLE [f3f70b8de] 2022-11-27 09:18:20 -0500
Branch: REL_13_STABLE [68d89d80c] 2022-11-27 09:18:32 -0500
Branch: REL_12_STABLE [85565cbca] 2022-11-27 09:18:40 -0500
Branch: REL_11_STABLE [724dd5649] 2022-11-27 09:18:46 -0500
-->
     <para>
      Fix mismatch of PL/Perl built with MSVC versus a Perl library built
      with gcc (Andrew Dunstan)
     </para>

     <para>
      Such combinations could previously fail with <quote>loadable library
      and perl binaries are mismatched</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [388e80132] 2022-12-29 12:47:29 -0800
Branch: REL_15_STABLE [c6e75e4c2] 2023-01-02 15:49:33 -0800
Branch: REL_14_STABLE [7b5dec760] 2023-01-02 15:50:00 -0800
Branch: REL_13_STABLE [ce073d014] 2023-01-02 15:50:33 -0800
Branch: REL_12_STABLE [f0e13802f] 2023-01-02 15:51:03 -0800
Branch: REL_11_STABLE [99f8bc335] 2023-01-02 15:51:05 -0800
-->
     <para>
      Suppress compiler warnings from Perl's header files (Andres Freund)
     </para>

     <para>
      Our preferred compiler options provoke warnings about constructs
      appearing in recent versions of Perl's header files.  When using
      <application>gcc</application>, we can suppress these warnings with
      a pragma.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_15_STABLE [9a40a0311] 2023-01-20 11:58:12 -0500
Branch: REL_14_STABLE [21c058648] 2023-01-20 11:58:12 -0500
Branch: REL_13_STABLE [c78f109b8] 2023-01-20 11:58:12 -0500
Branch: REL_12_STABLE [6d066d56b] 2023-01-20 11:58:12 -0500
Branch: REL_11_STABLE [b69e9dfab] 2023-01-20 11:58:12 -0500
-->
     <para>
      Fix <application>pg_waldump</application> to build on compilers that
      don't discard unused static-inline functions (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [758f44bc3] 2023-01-31 17:36:55 -0500
Branch: REL_15_STABLE [65f0d9d27] 2023-01-31 17:37:06 -0500
Branch: REL_14_STABLE [7e6154779] 2023-01-31 17:37:14 -0500
Branch: REL_13_STABLE [20d9da107] 2023-01-31 17:37:22 -0500
Branch: REL_12_STABLE [2c95d8776] 2023-01-31 17:37:28 -0500
Branch: REL_11_STABLE [7ddc428ef] 2023-01-31 17:37:34 -0500
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2022g for DST law changes in Greenland and Mexico,
      plus historical corrections for northern Canada, Colombia, and
      Singapore.
     </para>

     <para>
      Notably, a new timezone America/Ciudad_Juarez has been split off
      from America/Ojinaga.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-9">
  <title>Release 13.9</title>

  <formalpara>
  <title>Release date:</title>
  <para>2022-11-10</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.8.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.9</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you are upgrading from a version earlier than 13.7,
    see <xref linkend="release-13-7"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2dc2e4e31] 2022-09-30 19:37:00 -0400
Branch: REL_15_STABLE Release: REL_15_0 [2267085c1] 2022-09-30 19:36:46 -0400
Branch: REL_14_STABLE [b93d7e688] 2022-09-30 19:36:46 -0400
Branch: REL_13_STABLE [92941f264] 2022-09-30 19:36:46 -0400
Branch: REL_12_STABLE [e7bd2d671] 2022-09-30 19:36:46 -0400
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [163b0993a] 2022-09-22 11:04:00 -0700
Branch: REL_15_STABLE Release: REL_15_0 [dd6070bc8] 2022-09-22 11:04:36 -0700
Branch: REL_14_STABLE [21934612d] 2022-09-22 11:04:58 -0700
Branch: REL_13_STABLE [410c422b7] 2022-09-22 11:06:42 -0700
Branch: REL_12_STABLE [cab72f0fd] 2022-09-22 11:07:05 -0700
-->
     <para>
      Avoid rare PANIC during updates occurring concurrently
      with <command>VACUUM</command> (Tom Lane, Jeff Davis)
     </para>

     <para>
      If a concurrent <command>VACUUM</command> sets the all-visible flag
      bit in a page that <command>UPDATE</command>
      or <command>DELETE</command> is in process of modifying, the
      updating command needs to clear that bit again; but some code paths
      failed to do so, ending in a PANIC exit and database restart.
     </para>

     <para>
      This is known to be possible in versions 14 and 15.  It may be only
      latent in previous branches.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: REL_13_STABLE [43e409cea] 2022-09-05 11:20:05 -0700
Branch: REL_12_STABLE [7adc34832] 2022-09-05 11:20:03 -0700
Branch: REL_11_STABLE [a228cca46] 2022-09-05 11:20:01 -0700
Branch: REL_10_STABLE [cfe41f976] 2022-09-05 11:19:59 -0700
-->
     <para>
      Fix <command>VACUUM</command> to press on if an attempted page
      deletion in a btree index fails to find the page's parent downlink
      (Peter Geoghegan)
     </para>

     <para>
      Rather than throwing an error, just log the issue and continue
      without deleting the empty page.  Previously, a buggy operator class
      or corrupted index could indefinitely prevent completion of
      vacuuming of the index, eventually leading to transaction wraparound
      problems.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b8f2687fd] 2022-10-11 18:24:14 -0400
Branch: REL_15_STABLE [07ce67698] 2022-10-11 18:24:14 -0400
Branch: REL_14_STABLE [3162bd95c] 2022-10-11 18:24:14 -0400
Branch: REL_13_STABLE [21e042b0b] 2022-10-11 18:24:14 -0400
Branch: REL_12_STABLE [abc510fa2] 2022-10-11 18:24:15 -0400
Branch: REL_11_STABLE [addde9bc6] 2022-10-11 18:24:15 -0400
Branch: REL_10_STABLE [23e2a06ac] 2022-10-11 18:24:15 -0400
-->
     <para>
      Fix handling of <literal>DEFAULT</literal> tokens that appear
      in a multi-row <literal>VALUES</literal> clause of an
      <command>INSERT</command> on an updatable view (Tom Lane)
     </para>

     <para>
      This oversight could lead to <quote>cache lookup failed for
      type</quote> errors, or in older branches even to crashes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [797e313dc] 2022-10-17 12:14:39 -0400
Branch: REL_15_STABLE [4a41a069e] 2022-10-17 12:14:39 -0400
Branch: REL_14_STABLE [2f26cec48] 2022-10-17 12:14:39 -0400
Branch: REL_13_STABLE [b21615d1e] 2022-10-17 12:14:39 -0400
Branch: REL_12_STABLE [65c1106d8] 2022-10-17 12:14:39 -0400
Branch: REL_11_STABLE [e9377e3e5] 2022-10-17 12:14:39 -0400
Branch: REL_10_STABLE [ecf4ce689] 2022-10-17 12:14:39 -0400
-->
     <para>
      Disallow rules named <literal>_RETURN</literal> that are
      not <literal>ON SELECT</literal> (Tom Lane)
     </para>

     <para>
      This avoids confusion between a view's <literal>ON SELECT</literal>
      rule and any other rules it may have.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [216f9c1ab] 2022-09-25 17:10:58 -0400
Branch: REL_15_STABLE Release: REL_15_0 [c82766c02] 2022-09-25 17:10:58 -0400
Branch: REL_14_STABLE [992376461] 2022-09-25 17:10:58 -0400
Branch: REL_13_STABLE [8c17c8615] 2022-09-25 17:10:58 -0400
Branch: REL_12_STABLE [519763094] 2022-09-25 17:10:58 -0400
-->
     <para>
      Fix resource management bug in saving tuples
      for <literal>AFTER</literal> triggers (Tom Lane)
     </para>

     <para>
      Given the right circumstances, this manifested as a <quote>tupdesc
      reference <replaceable>NNNN</replaceable> is not owned by resource
      owner</quote> error followed by a PANIC exit.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_13_STABLE [3f7323cbb] 2022-08-27 12:11:20 -0400
Branch: REL_12_STABLE [f8e70cfb8] 2022-08-27 12:11:20 -0400
Branch: REL_11_STABLE [d9ebc582f] 2022-08-27 12:11:20 -0400
Branch: REL_10_STABLE [e1ea6f374] 2022-08-27 12:11:20 -0400
Branch: REL_13_STABLE [18f51083c] 2022-09-02 14:54:40 -0400
Branch: REL_12_STABLE [df92bc115] 2022-09-02 14:54:40 -0400
Branch: REL_11_STABLE [56dc44244] 2022-09-02 14:54:40 -0400
Branch: REL_10_STABLE [42d0d46f9] 2022-09-02 14:54:41 -0400
Branch: REL_13_STABLE [ccbb54c72] 2022-09-06 16:38:18 -0400
Branch: REL_12_STABLE [4d7c0fe51] 2022-09-06 16:38:18 -0400
Branch: REL_11_STABLE [9bcf6fb28] 2022-09-06 16:38:18 -0400
Branch: REL_10_STABLE [174c929e3] 2022-09-06 16:38:18 -0400
-->
     <para>
      Repair rare failure of MULTIEXPR_SUBLINK subplans in inherited
      updates (Tom Lane)
     </para>

     <para>
      Use of the syntax <literal>UPDATE tab SET (c1, ...) = (SELECT
      ...)</literal> with an inherited or partitioned target table could
      result in failure if the child tables are sufficiently dissimilar.
      This typically manifested as failure of consistency checks in the
      executor; but a crash or incorrect data updates are also possible.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [b0284bfb1] 2022-11-03 20:40:21 +0100
Branch: REL_15_STABLE [c301e1c0c] 2022-11-03 20:40:21 +0100
Branch: REL_14_STABLE [18865f4df] 2022-11-03 20:40:21 +0100
Branch: REL_13_STABLE [41b6e7c9a] 2022-11-03 20:40:21 +0100
Branch: REL_12_STABLE [ab70b3a52] 2022-11-03 20:40:21 +0100
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [614a406b4] 2022-10-07 19:37:48 +0200
Branch: REL_15_STABLE Release: REL_15_0 [6083132ab] 2022-10-07 19:37:48 +0200
Branch: REL_14_STABLE [483d26930] 2022-10-07 19:37:48 +0200
Branch: REL_13_STABLE [7d520e68e] 2022-10-07 19:37:48 +0200
Branch: REL_12_STABLE [669803af0] 2022-10-07 19:37:48 +0200
-->
     <para>
      Fix construction of per-partition foreign key constraints while
      doing <command>ALTER TABLE ATTACH PARTITION</command>
      (Jehan-Guillaume de Rorthais, &Aacute;lvaro Herrera)
     </para>

     <para>
      Previously, incorrect or duplicate constraints could be constructed
      for the newly-added partition.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [e7936f8b3] 2022-09-08 13:17:02 +0200
Branch: REL_15_STABLE Release: REL_15_0 [ade2409b1] 2022-09-08 13:17:02 +0200
Branch: REL_14_STABLE [640c20d62] 2022-09-08 13:17:02 +0200
Branch: REL_13_STABLE [80ef25b1a] 2022-09-08 13:17:02 +0200
Branch: REL_12_STABLE [562e100ae] 2022-09-08 13:17:02 +0200
-->
     <para>
      Fix generation of constraint names for per-partition foreign key
      constraints (Jehan-Guillaume de Rorthais)
     </para>

     <para>
      If the initially-given name is already in use for some constraint of
      the partition, a new one is selected; but it wasn't being spelled as
      intended.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e6dbb4848] 2022-08-18 12:12:03 -0400
Branch: REL_15_STABLE Release: REL_15_0 [2a42c1c51] 2022-08-18 12:12:03 -0400
Branch: REL_14_STABLE [3bfea5cbb] 2022-08-18 12:11:47 -0400
Branch: REL_13_STABLE [9f0073ef7] 2022-08-18 12:11:47 -0400
Branch: REL_12_STABLE [2cf16cd74] 2022-08-18 12:11:47 -0400
Branch: REL_11_STABLE [116f20f92] 2022-08-18 12:11:47 -0400
-->
     <para>
      Fix incorrect matching of index expressions and predicates when
      creating a partitioned index (Richard Guo, Tom Lane)
     </para>

     <para>
      While creating a partitioned index, we try to identify any existing
      indexes on the partitions that match the partitioned index, so that
      we can absorb those as child indexes instead of building new ones.
      Matching of expressions was not done right, so that a usable child
      index might be ignored, leading to creation of a duplicative index.
     </para>
    </listitem>

    <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master [6672d7913] 2022-08-29 11:07:37 -0400
Branch: REL_15_STABLE Release: REL_15_0 [eb29fa388] 2022-08-29 11:18:55 -0400
Branch: REL_14_STABLE [0e54a5e27] 2022-08-29 11:25:00 -0400
Branch: REL_13_STABLE [3f2701cda] 2022-08-29 11:30:17 -0400
Branch: REL_12_STABLE [3c0ef0832] 2022-08-29 11:55:49 -0400
Branch: REL_11_STABLE [002fba80e] 2022-08-29 12:06:30 -0400
Branch: REL_10_STABLE [0b3ff539d] 2022-08-29 12:21:50 -0400
-->
     <para>
      Prevent WAL corruption after a standby promotion (Dilip Kumar,
      Robert Haas)
     </para>

     <para>
      When a <productname>PostgreSQL</productname> instance performing
      archive recovery (but not using standby mode) is promoted, and the
      last WAL segment that it attempted to read ended in a partial
      record, the instance would write an invalid WAL segment on the new
      timeline.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [56b662523] 2022-10-13 09:31:57 +0900
Branch: REL_15_STABLE [ca4070f2b] 2022-10-26 09:41:13 +0900
Branch: REL_14_STABLE [5a30d43fa] 2022-10-26 09:41:18 +0900
Branch: REL_13_STABLE [594b97509] 2022-10-26 09:41:22 +0900
Branch: REL_12_STABLE [51c24d9e2] 2022-10-26 09:41:26 +0900
Branch: REL_11_STABLE [341fba2a6] 2022-10-26 09:41:28 +0900
Branch: REL_10_STABLE [b02fc7df1] 2022-10-26 09:41:31 +0900
-->
     <para>
      Fix mis-ordering of WAL operations in fast insert path for GIN
      indexes (Matthias van de Meent, Zhang Mingli)
     </para>

     <para>
      This mistake is not known to have any negative consequences within
      core <productname>PostgreSQL</productname>, but it did cause issues
      for some extensions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [16b1fe003] 2022-10-20 08:49:48 +0530
Branch: REL_15_STABLE [64ff0fe4e] 2022-10-20 09:43:59 +0530
Branch: REL_14_STABLE [a592ed923] 2022-10-20 09:34:18 +0530
Branch: REL_13_STABLE [25f7be1ca] 2022-10-20 09:25:13 +0530
Branch: REL_12_STABLE [1bf4d9206] 2022-10-20 09:16:28 +0530
Branch: REL_11_STABLE [5f7076cb6] 2022-10-20 09:07:04 +0530
Branch: REL_10_STABLE [10ed7b9e4] 2022-10-20 08:58:11 +0530
Branch: REL_15_STABLE [343afa967] 2022-10-21 10:03:35 +0530
Branch: REL_14_STABLE [4fbe6096b] 2022-10-21 09:52:44 +0530
Branch: REL_13_STABLE [38dbaaf27] 2022-10-21 09:42:24 +0530
Branch: REL_12_STABLE [02600886c] 2022-10-21 09:32:21 +0530
Branch: REL_11_STABLE [216af69ae] 2022-10-21 09:22:20 +0530
-->
     <para>
      Fix bugs in logical decoding when replay starts from a point
      between the beginning of a transaction and the beginning of its
      subtransaction (Masahiko Sawada, Kuroda Hayato)
     </para>

     <para>
      These errors could lead to assertion failures in debug builds, and
      otherwise to memory leaks.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: REL_15_STABLE Release: REL_15_0 [272248a0c] 2022-08-11 09:56:49 +0530
Branch: REL_14_STABLE [68dcce247] 2022-08-11 09:45:04 +0530
Branch: REL_13_STABLE [547b96368] 2022-08-11 09:30:55 +0530
Branch: REL_12_STABLE [794460783] 2022-08-11 09:09:36 +0530
Branch: REL_11_STABLE [e721123b7] 2022-08-11 08:55:31 +0530
Branch: REL_10_STABLE [bf0718c13] 2022-08-11 08:45:20 +0530
-->
     <para>
      Prevent examining system catalogs with the wrong snapshot during
      logical decoding (Masahiko Sawada)
     </para>

     <para>
      If decoding begins partway through a transaction that modifies
      system catalogs, the decoder may not recognize that, causing it to
      fail to treat that transaction as in-progress for catalog lookups.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [ce20f8b9f] 2022-10-21 12:57:18 +0530
Branch: REL_15_STABLE [10eaa9750] 2022-10-21 12:43:28 +0530
Branch: REL_14_STABLE [36fc013fa] 2022-10-21 12:33:47 +0530
Branch: REL_13_STABLE [1eed947f9] 2022-10-21 12:22:47 +0530
Branch: REL_12_STABLE [f7f82cf05] 2022-10-21 12:10:11 +0530
Branch: REL_11_STABLE [5c51afe23] 2022-10-21 12:08:14 +0530
Branch: REL_10_STABLE [61838d2dd] 2022-10-21 11:54:34 +0530
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [f972ec5c2] 2022-08-23 10:20:02 +0530
Branch: REL_15_STABLE Release: REL_15_0 [42681dffa] 2022-08-23 10:08:43 +0530
Branch: REL_14_STABLE [6d05d575b] 2022-08-23 09:24:51 +0530
Branch: REL_13_STABLE [4985a4591] 2022-08-23 09:10:28 +0530
Branch: REL_12_STABLE [9415873ae] 2022-08-23 08:51:20 +0530
Branch: REL_11_STABLE [51e9469a4] 2022-08-23 08:42:51 +0530
Branch: REL_10_STABLE [6b50433e8] 2022-08-23 08:39:31 +0530
-->
     <para>
      Accept interrupts in more places during logical decoding (Amit
      Kapila, Masahiko Sawada)
     </para>

     <para>
      This ameliorates problems with slow shutdown of replication workers.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [be541efbf] 2022-11-02 12:29:39 -0400
Branch: REL_15_STABLE [414d29a82] 2022-11-02 12:29:39 -0400
Branch: REL_14_STABLE [a5b7821fc] 2022-11-02 12:29:39 -0400
Branch: REL_13_STABLE [4d3f7e75c] 2022-11-02 12:29:39 -0400
-->
     <para>
      Prevent attempts to replicate into a foreign-table partition in
      replication workers (Shi Yu, Tom Lane)
     </para>

     <para>
      Although partitioned tables can have foreign tables as partitions,
      replicating into such a partition isn't currently supported.
      The logical replication worker process would crash if it was
      attempted.  Now, an error is thrown.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [0d5bd3a6c] 2022-08-16 15:25:41 +0530
Branch: REL_15_STABLE Release: REL_15_0 [76d257925] 2022-08-16 15:14:27 +0530
Branch: REL_14_STABLE [02f8d68af] 2022-08-16 14:51:42 +0530
Branch: REL_13_STABLE [1df86aac5] 2022-08-16 14:30:27 +0530
-->
     <para>
      Remove pointless check on replica identity setting of partitioned
      tables (Hou Zhijie)
     </para>

     <para>
      What matters is the replica identity setting of the leaf partitions,
      so there's no need to throw error if it's not set on the parent.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [dea834938] 2022-11-03 12:02:14 -0400
Branch: REL_15_STABLE [f2dc7f9e3] 2022-11-03 12:01:57 -0400
Branch: REL_14_STABLE [2489c38cd] 2022-11-03 12:01:57 -0400
Branch: REL_13_STABLE [b00f342ea] 2022-11-03 12:01:57 -0400
Branch: REL_12_STABLE [d9ffccf8d] 2022-11-03 12:01:57 -0400
Branch: REL_11_STABLE [ed019b5ef] 2022-11-03 12:01:57 -0400
Branch: REL_10_STABLE [5f3cec77b] 2022-11-03 12:01:57 -0400
-->
     <para>
      Avoid crash after function syntax error in replication workers
      (Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane)
     </para>

     <para>
      If a syntax error occurred in a SQL-language or PL/pgSQL-language
      <command>CREATE FUNCTION</command> or <command>DO</command> command
      executed in a logical replication worker, the worker process would
      crash with a null pointer dereference or assertion failure.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [309857f9c] 2022-08-10 13:37:25 -0400
Branch: REL_15_STABLE Release: REL_15_0 [ad3e07c15] 2022-08-10 13:37:25 -0400
Branch: REL_14_STABLE [95bfadd4e] 2022-08-10 13:37:25 -0400
Branch: REL_13_STABLE [71caf3c4d] 2022-08-10 13:37:25 -0400
Branch: REL_12_STABLE [5b948b5c1] 2022-08-10 13:37:25 -0400
Branch: REL_11_STABLE [442dbd669] 2022-08-10 13:37:25 -0400
Branch: REL_10_STABLE [1446612c5] 2022-08-10 13:37:25 -0400
-->
     <para>
      Fix handling of read-write expanded datums that are passed to SQL
      functions (Tom Lane)
     </para>

     <para>
      If a non-inlined SQL function uses a parameter in more than one
      place, and one of those functions expects to be able to modify
      read-write datums in place, then later uses of the parameter would
      observe the wrong value.  (Within
      core <productname>PostgreSQL</productname>, the expanded-datum
      mechanism is only used for array and composite-type values; but
      extensions might use it for other structured types.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Daniel Gustafsson <dgustafsson@postgresql.org>
Branch: master [8cb2a22bb] 2022-09-12 12:59:06 +0200
Branch: REL_15_STABLE Release: REL_15_0 [56d238846] 2022-09-12 12:59:06 +0200
Branch: REL_14_STABLE [13b8a1c19] 2022-09-12 12:59:06 +0200
Branch: REL_13_STABLE [eb8b84807] 2022-09-12 12:59:06 +0200
Branch: REL_12_STABLE [9ebfbd23b] 2022-09-12 12:59:06 +0200
-->
     <para>
      Fix type <type>circle</type>'s equality comparator to handle NaNs
      properly (Ranier Vilela)
     </para>

     <para>
      If the left-hand circle had a floating-point NaN for its radius,
      it would be considered equal to a circle with the same center and
      any radius.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1058555a5] 2022-08-31 10:42:05 -0400
Branch: REL_15_STABLE Release: REL_15_0 [61f6e5c23] 2022-08-31 10:42:05 -0400
Branch: REL_14_STABLE [e969f1ae2] 2022-08-31 10:42:05 -0400
Branch: REL_13_STABLE [f204ad3a2] 2022-08-31 10:42:05 -0400
Branch: REL_12_STABLE [a53e0ea78] 2022-08-31 10:42:05 -0400
Branch: REL_11_STABLE [f5aa855cd] 2022-08-31 10:42:05 -0400
Branch: REL_10_STABLE [cba393a10] 2022-08-31 10:42:05 -0400
-->
     <para>
      In Snowball dictionaries, don't try to stem excessively-long words
      (Olly Betts, Tom Lane)
     </para>

     <para>
      If the input word exceeds 1000 bytes, return it as-is after case
      folding, rather than trying to run it through the Snowball code.
      This restriction protects against a known
      recursion-to-stack-overflow problem in the Turkish stemmer, and it
      seems like good insurance against any other safety or performance
      issues that may exist in the Snowball stemmers.  Such a long string
      is surely not a word in any human language, so it's doubtful that
      the stemmer would have done anything desirable with it anyway.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a46621942] 2022-08-14 12:05:27 -0400
Branch: REL_15_STABLE Release: REL_15_0 [9ae484121] 2022-08-14 12:05:27 -0400
Branch: REL_14_STABLE [06602372b] 2022-08-14 12:05:27 -0400
Branch: REL_13_STABLE [9fe285f85] 2022-08-14 12:05:27 -0400
Branch: REL_12_STABLE [ee8a2f9d7] 2022-08-14 12:05:27 -0400
Branch: REL_11_STABLE [84f9691a1] 2022-08-14 12:05:27 -0400
Branch: REL_10_STABLE [d3cf15dfc] 2022-08-14 12:05:27 -0400
-->
     <para>
      Fix use-after-free hazard in string comparisons (Tom Lane)
     </para>

     <para>
      Improper memory management in the string comparison functions
      could result in scribbling on no-longer-allocated buffers,
      potentially breaking things for whatever is using that memory
      now.  This would only happen with fairly long strings (more than
      1kB), and only if an ICU collation is in use.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [eec346611] 2022-10-17 11:35:23 -0400
Branch: REL_15_STABLE [2e3326929] 2022-10-17 11:35:23 -0400
Branch: REL_14_STABLE [8c611602b] 2022-10-17 11:35:23 -0400
Branch: REL_13_STABLE [62b263bf7] 2022-10-17 11:35:23 -0400
Branch: REL_12_STABLE [99b6b705d] 2022-10-17 11:35:23 -0400
-->
     <para>
      Add plan-time check for attempted access to a table that has no
      table access method (Tom Lane)
     </para>

     <para>
      This prevents a crash in some catalog-corruption scenarios, for
      example use of a view whose <literal>ON SELECT</literal> rule is
      missing.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [18a4a620e] 2022-10-11 18:54:31 -0400
Branch: REL_15_STABLE [e7b4ff327] 2022-10-11 18:54:31 -0400
Branch: REL_14_STABLE [b10546ecf] 2022-10-11 18:54:31 -0400
Branch: REL_13_STABLE [744270137] 2022-10-11 18:54:31 -0400
Branch: REL_12_STABLE [8f98352b5] 2022-10-11 18:54:31 -0400
Branch: REL_11_STABLE [6c1de98ba] 2022-10-11 18:54:31 -0400
Branch: REL_10_STABLE [ab35b9dd7] 2022-10-11 18:54:31 -0400
-->
     <para>
      Prevent postmaster crash when shared-memory state is corrupted
      (Tom Lane)
     </para>

     <para>
      The postmaster process is supposed to survive and initiate a
      database restart if shared memory becomes corrupted, but one
      bit of code was being insufficiently cautious about that.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f25bed380] 2022-08-24 13:02:19 -0400
Branch: REL_15_STABLE Release: REL_15_0 [3d3c05c70] 2022-08-24 13:02:19 -0400
Branch: REL_14_STABLE [444ec169a] 2022-08-24 13:01:40 -0400
Branch: REL_13_STABLE [2d1f1523c] 2022-08-24 13:01:40 -0400
Branch: REL_12_STABLE [599a487b0] 2022-08-24 13:01:40 -0400
Branch: REL_11_STABLE [310d734ef] 2022-08-24 13:01:40 -0400
Branch: REL_10_STABLE [f5157a9ac] 2022-08-24 13:01:40 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e07ebd4b6] 2022-08-13 15:21:28 -0400
Branch: REL_15_STABLE Release: REL_15_0 [00ac61695] 2022-08-13 15:21:28 -0400
Branch: REL_14_STABLE [496ab1d6c] 2022-08-13 15:21:28 -0400
Branch: REL_13_STABLE [60f876317] 2022-08-13 15:21:28 -0400
Branch: REL_12_STABLE [ba516fb07] 2022-08-13 15:21:28 -0400
Branch: REL_11_STABLE [b744e13b0] 2022-08-13 15:21:28 -0400
Branch: REL_10_STABLE [362032f17] 2022-08-13 15:21:28 -0400
-->
     <para>
      Add some more defenses against recursion till stack overrun
      (Richard Guo, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [55d9cd46f] 2022-08-13 17:00:32 -0400
Branch: REL_15_STABLE Release: REL_15_0 [aee954373] 2022-08-13 16:59:58 -0400
Branch: REL_14_STABLE [1dfc9193a] 2022-08-13 16:59:58 -0400
Branch: REL_13_STABLE [4878ea717] 2022-08-13 16:59:58 -0400
-->
     <para>
      Avoid misbehavior when choosing hash table size with very
      small <varname>work_mem</varname> and large tuples (Zhang Mingli)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1c1294be7] 2022-08-31 16:23:35 -0400
Branch: REL_15_STABLE Release: REL_15_0 [0c599e748] 2022-08-31 16:23:20 -0400
Branch: REL_14_STABLE [feec1b2d5] 2022-08-31 16:23:20 -0400
Branch: REL_13_STABLE [45f7152b9] 2022-08-31 16:23:20 -0400
Branch: REL_12_STABLE [8fc6b9635] 2022-08-31 16:23:20 -0400
Branch: REL_11_STABLE [cb9232d16] 2022-08-31 16:23:20 -0400
Branch: REL_10_STABLE [fd640dbb8] 2022-08-31 16:23:20 -0400
-->
     <para>
      Avoid long-term memory leakage in the autovacuum launcher process
      (Reid Thompson)
     </para>

     <para>
      The lack of field reports suggests that this problem is only latent
      in pre-v15 branches; but it's not very clear why, so back-patch the
      fix anyway.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [bfd6b3bc4] 2022-09-16 13:23:01 -0400
Branch: REL_15_STABLE Release: REL_15_0 [b759bb671] 2022-09-16 13:23:01 -0400
Branch: REL_14_STABLE [56d45fdab] 2022-09-16 13:23:01 -0400
Branch: REL_13_STABLE [c18d946e2] 2022-09-16 13:23:01 -0400
Branch: REL_12_STABLE [b3b88d748] 2022-09-16 13:23:01 -0400
Branch: REL_11_STABLE [7391ab28a] 2022-09-16 13:23:01 -0400
-->
     <para>
      Improve <application>PL/pgSQL</application>'s ability to handle
      parameters declared as <type>RECORD</type> (Tom Lane)
     </para>

     <para>
      Build a separate function cache entry for each concrete type passed
      to the <type>RECORD</type> parameter during a session, much as we do
      for polymorphic parameters.  This allows some usages to work that
      previously failed with errors such as <quote>type of parameter does
      not match that when preparing the plan</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [bb9237a12] 2022-08-15 15:40:07 -0400
Branch: REL_15_STABLE Release: REL_15_0 [ef9f35964] 2022-08-15 15:40:07 -0400
Branch: REL_14_STABLE [d63a69157] 2022-08-15 15:40:07 -0400
Branch: REL_13_STABLE [e37e9a655] 2022-08-15 15:40:07 -0400
Branch: REL_12_STABLE [c19024d74] 2022-08-15 15:40:07 -0400
Branch: REL_11_STABLE [ee4a17e20] 2022-08-15 15:40:07 -0400
Branch: REL_10_STABLE [2a280832e] 2022-08-15 15:40:07 -0400
-->
     <para>
      Add missing guards for <literal>NULL</literal> connection pointer
      in <application>libpq</application> (Daniele Varrazzo, Tom Lane)
     </para>

     <para>
      There's a convention that <application>libpq</application> functions
      should check for a NULL PGconn argument, and fail gracefully instead
      of crashing.  <function>PQflush()</function>
      and <function>PQisnonblocking()</function> didn't get that memo, so
      fix them.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b7050e258] 2022-09-09 15:34:04 -0400
Branch: REL_15_STABLE Release: REL_15_0 [fbb54d742] 2022-09-09 15:34:04 -0400
Branch: REL_14_STABLE [be0b0528c] 2022-09-09 15:34:04 -0400
Branch: REL_13_STABLE [a6618842f] 2022-09-09 15:34:04 -0400
Branch: REL_12_STABLE [9fbc6d548] 2022-09-09 15:34:04 -0400
Branch: REL_11_STABLE [fe4e151d4] 2022-09-09 15:34:04 -0400
Branch: REL_10_STABLE [8fe26bca1] 2022-09-09 15:34:04 -0400
-->
     <para>
      In <application>ecpg</application>, fix omission of variable storage
      classes when multiple <type>varchar</type> or <type>bytea</type>
      variables are declared in the same declaration (Andrey Sokolov)
     </para>

     <para>
      For example, <application>ecpg</application>
      translated <literal>static varchar str1[10], str2[20],
      str3[30];</literal> in such a way that only <varname>str1</varname>
      was marked <literal>static</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master [1f0c4fa25] 2022-10-21 08:21:55 -0400
Branch: REL_15_STABLE [5c013e620] 2022-10-21 08:31:39 -0400
Branch: REL_14_STABLE [aaad8adb0] 2022-10-21 08:39:48 -0400
Branch: REL_13_STABLE [0bf2cd160] 2022-10-21 08:45:08 -0400
Branch: REL_12_STABLE [475e9daf3] 2022-10-21 08:59:26 -0400
Branch: REL_11_STABLE [38214dabd] 2022-10-21 09:05:57 -0400
Branch: REL_10_STABLE [ba58266eb] 2022-10-21 09:11:47 -0400
-->
     <para>
      Allow cross-platform tablespace relocation
      in <application>pg_basebackup</application> (Robert Haas)
     </para>

     <para>
      Allow the remote path in <option>--tablespace-mapping</option> to be
      either a Unix-style or Windows-style absolute path, since the source
      server could be on a different OS than the local system.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [495e73c20] 2022-11-01 12:48:01 -0400
Branch: REL_15_STABLE [8b0a5cf3f] 2022-11-01 12:48:01 -0400
Branch: REL_14_STABLE [0f2f5645a] 2022-11-01 12:48:01 -0400
Branch: REL_13_STABLE [a9fdb48b7] 2022-11-01 12:48:01 -0400
Branch: REL_12_STABLE [ca4c6764b] 2022-11-01 12:48:01 -0400
Branch: REL_11_STABLE [149e00192] 2022-11-01 12:48:01 -0400
Branch: REL_10_STABLE [56083ff30] 2022-11-01 12:48:01 -0400
-->
     <para>
      In <application>pg_stat_statements</application>, fix access to
      already-freed memory (zhaoqigui)
     </para>

     <para>
      This occurred if <application>pg_stat_statements</application>
      tracked a <command>ROLLBACK</command> command issued via extended
      query protocol.  In debug builds it consistently led to an assertion
      failure.  In production builds there would often be no visible ill
      effect; but if the freed memory had already been reused, the likely
      result would be to store garbage for the query string.
     </para>
    </listitem>

    <listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [9320cfdd0] 2022-09-14 18:45:00 +0900
Branch: REL_15_STABLE Release: REL_15_0 [64387c540] 2022-09-14 18:45:01 +0900
Branch: REL_14_STABLE [b53d104ae] 2022-09-14 18:45:03 +0900
Branch: REL_13_STABLE [6749d4e8c] 2022-09-14 18:45:04 +0900
Branch: REL_12_STABLE [87fd3c902] 2022-09-14 18:45:06 +0900
Branch: REL_11_STABLE [07d81d1e5] 2022-09-14 18:45:07 +0900
Branch: REL_10_STABLE [d4adff0e9] 2022-09-14 18:45:09 +0900
-->
     <para>
      In <application>postgres_fdw</application>, ensure that target lists
      constructed for EvalPlanQual plans will have all required columns
      (Richard Guo, Etsuro Fujita)
     </para>

     <para>
      This avoids <quote>variable not found in subplan target list</quote>
      errors in rare cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c4b6d218e] 2022-09-09 12:41:36 -0400
Branch: REL_15_STABLE Release: REL_15_0 [100a8ca2c] 2022-09-09 12:41:36 -0400
Branch: REL_14_STABLE [e55ccb3b1] 2022-09-09 12:41:36 -0400
Branch: REL_13_STABLE [a61095aa7] 2022-09-09 12:41:36 -0400
Branch: REL_12_STABLE [23fe89a61] 2022-09-09 12:41:36 -0400
Branch: REL_11_STABLE [4d3f54bd7] 2022-09-09 12:41:36 -0400
Branch: REL_10_STABLE [95028d9de] 2022-09-09 12:41:36 -0400
-->
     <para>
      Reject unwanted output from the platform's
      <function>uuid_create()</function> function (Nazir Bilal Yavuz)
     </para>

     <para>
      The <application>uuid-ossp</application> module expects
      libc's <function>uuid_create()</function> to produce a version-1
      UUID, but recent NetBSD releases produce a version-4 (random) UUID
      instead.  Check for that, and complain if so.  Drop the
      documentation's claim that the NetBSD implementation is usable
      for <application>uuid-ossp</application>.
      (If a version-4 UUID is okay for your purposes, you don't
      need <application>uuid-ossp</application> at all; just
      use <function>gen_random_uuid()</function>.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: REL_14_STABLE [4f6d1cfd6] 2022-10-11 09:56:13 +0200
Branch: REL_13_STABLE [33d979aee] 2022-10-11 09:56:13 +0200
Branch: REL_12_STABLE [fa5c13178] 2022-10-11 09:56:13 +0200
Branch: REL_11_STABLE [dd8263873] 2022-10-11 09:56:13 +0200
Branch: REL_10_STABLE [8bf470527] 2022-10-11 09:56:13 +0200
-->
     <para>
      Include new Perl test modules in standard installations
      (&Aacute;lvaro Herrera)
     </para>

     <para>
      Add <filename>PostgreSQL/Test/Cluster.pm</filename> and
      <filename>PostgreSQL/Test/Utils.pm</filename> to the standard
      installation file set in pre-version-15 branches.  This is for the
      benefit of extensions that want to use newly-written test code in
      older branches.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8acd8f869] 2022-08-30 17:28:37 -0400
Branch: REL_15_STABLE Release: REL_15_0 [529d8f373] 2022-08-30 17:28:55 -0400
Branch: REL_14_STABLE [464db4676] 2022-08-30 17:29:03 -0400
Branch: REL_13_STABLE [a94b019d4] 2022-08-30 17:29:08 -0400
Branch: REL_12_STABLE [68bfe36c5] 2022-08-30 17:29:13 -0400
Branch: REL_11_STABLE [6fd58ca77] 2022-08-30 17:29:17 -0400
Branch: REL_10_STABLE [5bed28e69] 2022-08-30 17:29:23 -0400
-->
     <para>
      On NetBSD, force dynamic symbol resolution at postmaster start
      (Andres Freund, Tom Lane)
     </para>

     <para>
      This avoids a risk of deadlock in the dynamic linker on NetBSD 10.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [c2ae01f69] 2022-10-19 22:18:26 +1300
Branch: REL_15_STABLE [af64846e1] 2022-10-19 22:18:54 +1300
Branch: REL_14_STABLE [d033f8f8b] 2022-10-19 22:32:14 +1300
Branch: REL_13_STABLE [cf94cb586] 2022-10-19 22:38:58 +1300
Branch: REL_12_STABLE [aa34bc4e2] 2022-10-19 22:44:53 +1300
Branch: REL_11_STABLE [da3a6825e] 2022-10-19 22:49:25 +1300
-->
     <para>
      Fix incompatibilities with LLVM 15 (Thomas Munro, Andres Freund)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1c72d82c2] 2022-11-02 17:37:29 -0400
Branch: REL_15_STABLE [a5737e765] 2022-11-02 17:37:26 -0400
Branch: REL_14_STABLE [058c7b5dd] 2022-11-02 17:37:26 -0400
Branch: REL_13_STABLE [c479492c0] 2022-11-02 17:37:26 -0400
Branch: REL_12_STABLE [5ecf836e9] 2022-11-02 17:37:26 -0400
Branch: REL_11_STABLE [a0f9be1f9] 2022-11-02 17:37:26 -0400
Branch: REL_10_STABLE [19cefebe7] 2022-11-02 17:37:26 -0400
-->
     <para>
      Allow use of <function>__sync_lock_test_and_set()</function> for
      spinlocks on any machine (Tom Lane)
     </para>

     <para>
      This eases porting to new machine architectures, at least if you're
      using a compiler that supports this GCC builtin function.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [717ec1aae] 2022-10-16 15:27:04 -0400
Branch: REL_15_STABLE [24c4c2617] 2022-10-16 15:27:04 -0400
Branch: REL_14_STABLE [18e60712d] 2022-10-16 15:27:04 -0400
Branch: REL_13_STABLE [bc7a40b42] 2022-10-16 15:27:04 -0400
Branch: REL_12_STABLE [3d7df87c4] 2022-10-16 15:27:04 -0400
Branch: REL_11_STABLE [6618c276b] 2022-10-16 15:27:04 -0400
Branch: REL_10_STABLE [02d074e3e] 2022-10-16 15:27:04 -0400
Branch: REL9_6_STABLE [9bfa043a1] 2022-10-16 15:27:04 -0400
Branch: REL9_5_STABLE [377b37cf7] 2022-10-16 15:27:04 -0400
Branch: REL9_4_STABLE [57dfb6ce6] 2022-10-16 15:27:04 -0400
Branch: REL9_3_STABLE [ee4c44014] 2022-10-16 15:27:04 -0400
Branch: REL9_2_STABLE [fec443414] 2022-10-16 15:27:04 -0400
-->
     <para>
      Rename symbol <literal>REF</literal> to <literal>REF_P</literal> to
      avoid compile failure on recent macOS (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [450ee7012] 2022-10-16 11:47:44 -0400
Branch: REL_15_STABLE [bd4b2926e] 2022-10-16 11:47:44 -0400
Branch: REL_14_STABLE [6fa431d84] 2022-10-16 11:47:44 -0400
Branch: REL_13_STABLE [a2acafc7b] 2022-10-16 11:47:44 -0400
Branch: REL_12_STABLE [d33ac1ec2] 2022-10-16 11:47:44 -0400
-->
     <para>
      Avoid using <function>sprintf</function>, to avoid compile-time
      deprecation warnings (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_15_STABLE Release: REL_15_0 [f9a56e726] 2022-09-20 18:59:53 -0400
Branch: REL_14_STABLE [dcd7dbed5] 2022-09-20 18:59:53 -0400
Branch: REL_13_STABLE [43f72e0f7] 2022-09-20 18:59:53 -0400
Branch: REL_12_STABLE [52a5fd5b9] 2022-09-20 18:59:53 -0400
Branch: REL_11_STABLE [9afdf3950] 2022-09-20 18:59:53 -0400
Branch: REL_10_STABLE [4c5a29c0e] 2022-09-20 18:59:53 -0400
Branch: REL9_6_STABLE [ca8fd341e] 2022-09-20 18:59:53 -0400
Branch: REL9_5_STABLE [1b6986599] 2022-09-20 18:59:53 -0400
Branch: REL9_4_STABLE [7d5d3f05b] 2022-09-20 18:59:53 -0400
Branch: REL9_3_STABLE [8c8ee5c99] 2022-09-20 18:59:54 -0400
Branch: REL9_2_STABLE [5d3ce0d82] 2022-09-20 18:59:54 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [152c9f7b8] 2022-09-20 12:04:37 -0400
Branch: REL_15_STABLE Release: REL_15_0 [b7d9b0c26] 2022-09-20 12:04:37 -0400
Branch: REL_14_STABLE [2e124d857] 2022-09-20 12:04:37 -0400
Branch: REL_13_STABLE [ca3b730ba] 2022-09-20 12:04:37 -0400
Branch: REL_12_STABLE [f38a0bde2] 2022-09-20 12:04:37 -0400
Branch: REL_11_STABLE [6ae8aee0b] 2022-09-20 12:04:37 -0400
Branch: REL_10_STABLE [760308704] 2022-09-20 12:04:37 -0400
Branch: REL9_6_STABLE [85c077f9e] 2022-09-20 12:04:37 -0400
Branch: REL9_5_STABLE [612e79661] 2022-09-20 12:04:37 -0400
Branch: REL_14_STABLE [88c947cb5] 2022-09-21 13:52:38 -0400
Branch: REL_13_STABLE [db8e36682] 2022-09-21 13:52:38 -0400
Branch: REL_12_STABLE [9a2267bcf] 2022-09-21 13:52:38 -0400
Branch: REL_11_STABLE [bb8dbc9f2] 2022-09-21 13:52:38 -0400
Branch: REL_10_STABLE [9c69e2640] 2022-09-21 13:52:38 -0400
Branch: REL9_6_STABLE [c705646b7] 2022-09-21 13:52:38 -0400
Branch: REL9_5_STABLE [96e595124] 2022-09-21 13:52:38 -0400
Branch: REL9_4_STABLE [3c5a33a52] 2022-09-21 13:52:38 -0400
Branch: REL9_3_STABLE [bf2161234] 2022-09-21 13:52:38 -0400
Branch: REL9_2_STABLE [850cb88e4] 2022-09-21 13:52:38 -0400
-->
     <para>
      Silence assorted compiler warnings from clang 15 and later (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e7c7605a7] 2022-11-01 17:08:28 -0400
Branch: REL_15_STABLE [c3d16eb3d] 2022-11-01 17:08:49 -0400
Branch: REL_14_STABLE [97bb80b1b] 2022-11-01 17:08:58 -0400
Branch: REL_13_STABLE [ebf48810b] 2022-11-01 17:09:04 -0400
Branch: REL_12_STABLE [ec9a000d8] 2022-11-01 17:09:09 -0400
Branch: REL_11_STABLE [b1cb77bdf] 2022-11-01 17:09:16 -0400
Branch: REL_10_STABLE [b3326a753] 2022-11-01 17:09:21 -0400
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2022f for DST law changes in Chile, Fiji, Iran, Jordan,
      Mexico, Palestine, and Syria, plus historical corrections for Chile,
      Crimea, Iran, and Mexico.
     </para>

     <para>
      Also, the Europe/Kiev zone has been renamed to Europe/Kyiv.
      Also, the following zones have been merged into nearby,
      more-populous zones whose clocks have agreed with them since 1970:
      Antarctica/Vostok, Asia/Brunei,
      Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam,
      Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo,
      Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen,
      Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti,
      Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis.
      (This indirectly affects zones that were already links to one of
      these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland,
      Pacific/Ponape, Pacific/Truk, and Pacific/Yap.)  America/Nipigon,
      America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and
      Europe/Zaporozhye were also merged into nearby zones after
      discovering that their claimed post-1970 differences from those
      zones seem to have been errors.
      In all these cases, the previous zone name remains as an alias;
      but the actual data is that of the zone that was merged into.
     </para>

     <para>
      These zone mergers result in loss of pre-1970 timezone history for
      the merged zones, which may be troublesome for applications
      expecting consistency of <type>timestamptz</type> display.  As an
      example, the stored value <literal>1944-06-01 12:00 UTC</literal>
      would previously display as <literal>1944-06-01
      13:00:00+01</literal> if the Europe/Stockholm zone is selected, but
      now it will read out as <literal>1944-06-01 14:00:00+02</literal>.
     </para>

     <para>
      It is possible to build the time zone data files with options that
      will restore the older zone data, but that choice also inserts a lot
      of other old (and typically poorly-attested) zone data, resulting in
      more total changes from the previous release than accepting these
      upstream changes does.  <productname>PostgreSQL</productname> has
      chosen to ship the <productname>tzdb</productname> data
      as-recommended, and so far as we are aware most major operating
      system distributions are doing likewise.  However, if these changes
      cause significant problems for your application, a possible solution
      is to install a local build of the time zone data files using
      <productname>tzdb</productname>'s backwards-compatibility options
      (see their <literal>PACKRATDATA</literal>
      and <literal>PACKRATLIST</literal> options).
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-8">
  <title>Release 13.8</title>

  <formalpara>
  <title>Release date:</title>
  <para>2022-08-11</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.7.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.8</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you are upgrading from a version earlier than 13.7,
    see <xref linkend="release-13-7"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b9b21acc7] 2022-08-08 11:12:31 -0400
Branch: REL_15_STABLE [cc7e0feba] 2022-08-08 11:12:31 -0400
Branch: REL_14_STABLE [5721da7e4] 2022-08-08 11:12:31 -0400
Branch: REL_13_STABLE [7e92f78ab] 2022-08-08 11:12:31 -0400
Branch: REL_12_STABLE [5579726bd] 2022-08-08 11:12:31 -0400
Branch: REL_11_STABLE [f52d2fbd8] 2022-08-08 11:12:31 -0400
Branch: REL_10_STABLE [5919bb5a5] 2022-08-08 11:12:31 -0400
-->
     <para>
      Do not let extension scripts replace objects not already belonging
      to the extension (Tom Lane)
     </para>

     <para>
      This change prevents extension scripts from doing <command>CREATE
      OR REPLACE</command> if there is an existing object that does not
      belong to the extension.  It also prevents <command>CREATE IF NOT
      EXISTS</command> in the same situation.  This prevents a form of
      trojan-horse attack in which a hostile database user could become
      the owner of an extension object and then modify it to compromise
      future uses of the object by other users.  As a side benefit, it
      also reduces the risk of accidentally replacing objects one did
      not mean to.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Sven Klemm for reporting this problem.
      (CVE-2022-2625)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [9e4f914b5] 2022-07-28 08:40:06 +0200
Branch: REL_15_STABLE [8348413db] 2022-07-28 08:26:05 +0200
Branch: REL_14_STABLE [a3aacb7cb] 2022-07-28 08:26:05 +0200
Branch: REL_13_STABLE [9a7e26b9c] 2022-07-28 08:26:05 +0200
Branch: REL_12_STABLE [6d20f8c5a] 2022-07-28 08:26:05 +0200
Branch: REL_11_STABLE [5a10c262f] 2022-07-28 08:26:05 +0200
Branch: REL_10_STABLE [084318c33] 2022-07-28 08:26:05 +0200
Branch: master [59be1c942] 2022-07-29 12:50:47 +0200
Branch: REL_15_STABLE [798d64488] 2022-07-29 12:50:47 +0200
Branch: REL_14_STABLE [4d8d85740] 2022-07-29 12:50:47 +0200
Branch: REL_13_STABLE [7cfe688de] 2022-07-29 12:50:47 +0200
Branch: REL_12_STABLE [658e5d534] 2022-07-29 12:50:47 +0200
Branch: REL_11_STABLE [fcd72cf29] 2022-07-29 12:50:47 +0200
Branch: REL_10_STABLE [6ffaf75a8] 2022-07-29 12:50:47 +0200
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [b998196bb] 2022-07-29 17:54:19 -0400
Branch: REL_15_STABLE [2eb3f167f] 2022-07-29 18:17:17 -0400
Branch: REL_14_STABLE [e90c4fc88] 2022-07-29 18:17:30 -0400
Branch: REL_13_STABLE [b76e136ce] 2022-07-29 18:17:36 -0400
Branch: REL_12_STABLE [4349a7615] 2022-07-29 18:17:42 -0400
Branch: REL_11_STABLE [3f9c20536] 2022-07-29 18:17:49 -0400
Branch: REL_10_STABLE [c308003d2] 2022-07-29 18:17:55 -0400
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [6c1c9f88a] 2022-08-06 15:52:10 +0200
Branch: REL_15_STABLE [6390bc740] 2022-08-06 15:52:10 +0200
Branch: REL_14_STABLE [9d5c96d9b] 2022-08-06 15:52:10 +0200
Branch: REL_13_STABLE [8c5d9ccca] 2022-08-06 15:52:10 +0200
Branch: REL_12_STABLE [782e5631e] 2022-08-06 15:52:10 +0200
Branch: REL_11_STABLE [772e6383d] 2022-08-06 15:52:10 +0200
Branch: REL_10_STABLE [ad0e08394] 2022-08-06 15:52:10 +0200
-->
     <para>
      Fix replay of <command>CREATE DATABASE</command> WAL
      records on standby servers
      (Kyotaro Horiguchi, Asim R Praveen, Paul Guo)
     </para>

     <para>
      Standby servers may encounter missing tablespace directories
      when replaying database-creation WAL records.  Prior to this
      patch, a standby would fail to recover in such a case;
      however, such directories could be legitimately missing.
      Create the tablespace (as a plain directory), then check that it
      has been dropped again once replay reaches a consistent state.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: REL_14_STABLE [961cab0a5] 2022-07-27 07:55:13 +0200
Branch: REL_13_STABLE [16e7a8fd8] 2022-07-27 07:55:13 +0200
Branch: REL_12_STABLE [ca347f543] 2022-07-27 07:55:12 +0200
Branch: REL_11_STABLE [258c89641] 2022-07-27 07:55:12 +0200
Branch: REL_10_STABLE [7bdbbb873] 2022-07-27 07:55:12 +0200
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [9d3444dcc] 2022-07-22 16:57:12 +1200
Branch: REL_15_STABLE [6d306ab73] 2022-07-22 16:57:36 +1200
Branch: REL_14_STABLE [fee0165fc] 2022-07-22 16:57:57 +1200
Branch: master [4fc6b6eef] 2022-07-28 14:26:12 +1200
Branch: REL_15_STABLE [fc4e5af30] 2022-07-28 14:27:28 +1200
Branch: REL_14_STABLE [5ad478c9d] 2022-07-28 14:27:06 +1200
-->
     <para>
      Support <quote>in place</quote> tablespaces
      (Thomas Munro, Michael Paquier, &Aacute;lvaro Herrera)
     </para>

     <para>
      Normally a Postgres tablespace is a symbolic link to a directory on
      some other filesystem.  This change allows it to just be a plain
      directory.  While this has no use for separating tables onto
      different filesystems, it is a convenient setup for testing.
      Moreover, it is necessary to support the <command>CREATE
      DATABASE</command> replay fix, which transiently creates a missing
      tablespace as an <quote>in place</quote> tablespace.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master Release: REL_15_BR [00377b9a0] 2022-06-25 09:07:41 -0700
Branch: REL_14_STABLE [ace997386] 2022-06-25 09:07:44 -0700
Branch: REL_13_STABLE [8782ce49e] 2022-06-25 09:07:45 -0700
Branch: REL_12_STABLE [93731d549] 2022-06-25 09:07:45 -0700
Branch: REL_11_STABLE [6d49cc286] 2022-06-25 09:07:46 -0700
Branch: REL_10_STABLE [88b39e614] 2022-06-25 09:07:46 -0700
-->
     <para>
      Fix permissions checks in <command>CREATE INDEX</command> (Nathan
      Bossart, Noah Misch)
     </para>

     <para>
      The fix for CVE-2022-1552 caused <command>CREATE INDEX</command> to
      apply the table owner's permissions while performing lookups of
      operator classes and other objects, where formerly the calling
      user's permissions were used.  This broke dump/restore scenarios,
      because <application>pg_dump</application> issues <command>CREATE
      INDEX</command> before re-granting permissions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f92944137] 2022-07-26 13:07:03 -0400
Branch: REL_15_STABLE [a0c632c1d] 2022-07-26 13:07:03 -0400
Branch: REL_14_STABLE [3e1297a63] 2022-07-26 13:07:03 -0400
Branch: REL_13_STABLE [6c193c2ac] 2022-07-26 13:07:03 -0400
Branch: REL_12_STABLE [968b89257] 2022-07-26 13:07:03 -0400
Branch: REL_11_STABLE [9e3e1ac45] 2022-07-26 13:07:03 -0400
Branch: REL_10_STABLE [964f42aa2] 2022-07-26 13:07:03 -0400
-->
     <para>
      In extended query protocol, force an immediate commit
      after <command>CREATE DATABASE</command> and other commands that
      can't run in a transaction block (Tom Lane)
     </para>

     <para>
      If the client does not send a Sync message immediately after such a
      command, but instead sends another command, any failure in that
      command would lead to rolling back the preceding command, typically
      leaving inconsistent state on-disk (such as a missing or extra
      database directory).  The mechanisms intended to prevent that
      situation turn out to work for multiple commands in a simple-Query
      message, but not for a series of extended-protocol messages.  To
      prevent inconsistency without breaking use-cases that work today,
      force an implicit commit after such commands.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master Release: REL_15_BR [adf6d5dfb] 2022-06-27 08:21:08 +0300
Branch: REL_14_STABLE [e24615a00] 2022-06-27 08:24:30 +0300
Branch: REL_13_STABLE [7ba325fd7] 2022-06-27 08:24:35 +0300
Branch: REL_12_STABLE [af530898e] 2022-06-27 08:24:36 +0300
Branch: REL_11_STABLE [b49889f3c] 2022-06-27 08:24:37 +0300
Branch: REL_10_STABLE [4822b4627] 2022-06-27 08:24:38 +0300
-->
     <para>
      Fix race condition when checking transaction visibility (Simon Riggs)
     </para>

     <para>
      <function>TransactionIdIsInProgress</function> could
      report <literal>false</literal> before the subject transaction is
      considered visible, leading to various misbehaviors.  The race
      condition window is normally very narrow, but use of synchronous
      replication makes it much wider, because the wait for a synchronous
      replica happens in that window.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [1218780cc] 2022-06-10 10:35:57 -0400
Branch: REL_14_STABLE Release: REL_14_4 [77c1d92cb] 2022-06-10 10:35:57 -0400
Branch: REL_13_STABLE [254cd7f31] 2022-06-10 10:35:57 -0400
Branch: REL_12_STABLE [d3ef5c3ef] 2022-06-10 10:35:57 -0400
Branch: REL_11_STABLE [199aac8b2] 2022-06-10 10:35:57 -0400
-->
     <para>
      Fix queries in which a <quote>whole-row variable</quote> references
      the result of a function that returns a domain over composite type
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [79b58c6f6] 2022-05-12 11:31:46 -0400
Branch: REL_14_STABLE Release: REL_14_4 [ac51c9fba] 2022-05-12 11:31:46 -0400
Branch: REL_13_STABLE [b7579b25c] 2022-05-12 11:31:46 -0400
Branch: REL_12_STABLE [301b91c56] 2022-05-12 11:31:46 -0400
Branch: REL_11_STABLE [7f7f1750d] 2022-05-12 11:31:46 -0400
Branch: REL_10_STABLE [b53442f6f] 2022-05-12 11:31:46 -0400
-->
     <para>
      Fix <quote>variable not found in subplan target list</quote> planner
      error when pulling up a sub-<literal>SELECT</literal> that's
      referenced in a <literal>GROUPING</literal> function (Richard Guo)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1aa8dad41] 2022-08-03 17:33:42 -0400
Branch: REL_15_STABLE [14168d57b] 2022-08-03 17:33:42 -0400
Branch: REL_14_STABLE [445b9020c] 2022-08-03 17:33:42 -0400
Branch: REL_13_STABLE [da4ed7588] 2022-08-03 17:33:42 -0400
Branch: master [cc1164799] 2022-08-04 11:11:33 -0400
Branch: REL_15_STABLE [11e7d626c] 2022-08-04 11:11:22 -0400
Branch: REL_14_STABLE [1a9ac8492] 2022-08-04 11:11:22 -0400
Branch: REL_13_STABLE [8d38ccafc] 2022-08-04 11:11:22 -0400
-->
     <para>
      Fix incorrect plans when sorting by an expression that contains a
      non-top-level set-returning function (Richard Guo, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [94da73281] 2022-08-05 13:58:47 -0400
Branch: REL_15_STABLE [b6d147bcb] 2022-08-05 13:58:48 -0400
Branch: REL_14_STABLE [ea6c91696] 2022-08-05 13:58:48 -0400
Branch: REL_13_STABLE [c102d1106] 2022-08-05 13:58:49 -0400
Branch: master [4c81a50e5] 2022-08-05 15:57:46 -0400
Branch: REL_15_STABLE [6303df08f] 2022-08-05 15:57:46 -0400
Branch: REL_14_STABLE [b9243cada] 2022-08-05 15:57:46 -0400
Branch: REL_13_STABLE [476f9d533] 2022-08-05 15:57:46 -0400
-->
     <para>
      Avoid planner core dump with <literal><replaceable>constant</replaceable>
      = ANY(<replaceable>array</replaceable>)</literal> clauses when
      there are MCV-type extended statistics on
      the <replaceable>array</replaceable> variable (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [ec0925c22] 2022-08-05 09:47:26 +0200
Branch: REL_15_STABLE [e78fd9084] 2022-08-05 09:47:15 +0200
Branch: REL_14_STABLE [731d514ae] 2022-08-05 09:47:11 +0200
Branch: REL_13_STABLE [ab8556630] 2022-08-05 09:47:06 +0200
Branch: REL_12_STABLE [6e7b37264] 2022-08-05 09:47:02 +0200
Branch: REL_11_STABLE [ce8e06652] 2022-08-05 09:46:58 +0200
Branch: master [90a4b6413] 2022-08-05 11:55:52 +0200
Branch: REL_15_STABLE [aa242501a] 2022-08-05 11:55:52 +0200
Branch: REL_14_STABLE [6d9481cd0] 2022-08-05 11:55:52 +0200
Branch: REL_13_STABLE [d2a74621e] 2022-08-05 11:55:52 +0200
Branch: REL_12_STABLE [4ad4c1f41] 2022-08-05 11:55:52 +0200
Branch: REL_11_STABLE [91130dd31] 2022-08-05 11:55:52 +0200
-->
     <para>
      Fix <literal>ALTER TABLE ... ENABLE/DISABLE TRIGGER</literal> to
      handle recursion correctly for triggers on partitioned tables
      (&Aacute;lvaro Herrera, Amit Langote)
     </para>

     <para>
      In certain cases, a <quote>trigger does not exist</quote> failure
      would occur because the command would try to adjust the trigger on a
      child partition that doesn't have it.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [89a39d4a4] 2022-07-03 17:08:25 -0400
Branch: REL_15_STABLE [7d9bf589b] 2022-07-03 17:27:03 -0400
Branch: REL_14_STABLE [7fd43684f] 2022-07-03 17:16:11 -0400
Branch: REL_13_STABLE [03cefe814] 2022-07-03 17:16:58 -0400
Branch: REL_12_STABLE [2cf875a4b] 2022-07-03 17:17:08 -0400
-->
     <para>
      Improve syntax error messages for type <type>jsonpath</type>
      (Andrew Dunstan)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [bf4717b09] 2022-06-07 15:34:30 -0400
Branch: REL_14_STABLE Release: REL_14_4 [5c3b5f7db] 2022-06-07 15:34:30 -0400
Branch: REL_13_STABLE [a36196972] 2022-06-07 15:34:30 -0400
Branch: REL_12_STABLE [435251b85] 2022-06-07 15:34:30 -0400
Branch: REL_11_STABLE [d628ce048] 2022-06-07 15:34:30 -0400
Branch: REL_10_STABLE [fb646cbd5] 2022-06-07 15:34:30 -0400
-->
     <para>
      Prevent <function>pg_stat_get_subscription()</function> from
      possibly returning an extra row containing garbage values
      (Kuntal Ghosh)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [b24b2be11] 2022-07-20 09:57:01 +0900
Branch: REL_15_STABLE [0829cc43e] 2022-07-20 09:57:07 +0900
Branch: REL_14_STABLE [be2e842c8] 2022-07-20 09:53:37 +0900
Branch: REL_13_STABLE [162ade612] 2022-07-20 09:53:53 +0900
Branch: REL_12_STABLE [f0eb83f81] 2022-07-20 09:54:03 +0900
Branch: REL_11_STABLE [80c3ea918] 2022-07-20 09:54:10 +0900
Branch: REL_10_STABLE [2497d2b77] 2022-07-20 09:54:24 +0900
-->
     <para>
      Ensure that <function>pg_stop_backup()</function> cleans up session
      state properly (Fujii Masao)
     </para>

     <para>
      This omission could lead to assertion failures or crashes later in
      the session.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [8d367a44d] 2022-07-07 13:08:08 +0100
Branch: REL_15_STABLE [ea9e59d70] 2022-07-07 13:08:06 +0100
Branch: REL_14_STABLE [8d8464445] 2022-07-07 13:08:03 +0100
Branch: REL_13_STABLE [f890223bc] 2022-07-07 13:08:00 +0100
Branch: REL_12_STABLE [f9c655d64] 2022-07-07 13:07:57 +0100
Branch: REL_11_STABLE [e88b1f1e2] 2022-07-07 13:07:54 +0100
Branch: REL_10_STABLE [8ace122d4] 2022-07-07 13:07:51 +0100
-->
     <para>
      Fix join alias matching in <literal>FOR [KEY] UPDATE/SHARE</literal>
      clauses (Dean Rasheed)
     </para>

     <para>
      In corner cases, a misleading error could be reported.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master Release: REL_15_BR [0fbf01120] 2022-05-18 20:28:31 +0200
Branch: REL_14_STABLE Release: REL_14_4 [94edb85d2] 2022-05-18 20:28:31 +0200
Branch: REL_13_STABLE [80656f00f] 2022-05-18 20:28:31 +0200
Branch: REL_12_STABLE [ade17703d] 2022-05-18 20:28:31 +0200
Branch: REL_11_STABLE [ba83de8ad] 2022-05-18 20:28:31 +0200
Branch: REL_10_STABLE [16cb7db34] 2022-05-18 20:28:31 +0200
Branch: master Release: REL_15_BR [62221ef18] 2022-05-18 23:19:53 +0200
Branch: REL_14_STABLE Release: REL_14_4 [e8b93c6e2] 2022-05-18 23:19:53 +0200
Branch: REL_13_STABLE [5139db556] 2022-05-18 23:19:53 +0200
Branch: REL_12_STABLE [0ebd20e20] 2022-05-18 23:19:53 +0200
Branch: REL_11_STABLE [50bf3157a] 2022-05-18 23:19:53 +0200
Branch: REL_10_STABLE [29d111518] 2022-05-18 23:19:53 +0200
-->
     <para>
      Avoid crashing if too many column aliases are attached to
      an <literal>XMLTABLE</literal> or <literal>JSON_TABLE</literal>
      construct (&Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [fd96d14d9] 2022-07-29 13:31:10 -0400
Branch: REL_15_STABLE [e6e804aa2] 2022-07-29 13:31:11 -0400
Branch: REL_14_STABLE [8df167baa] 2022-07-29 13:30:50 -0400
Branch: REL_13_STABLE [ba2002d02] 2022-07-29 13:30:50 -0400
Branch: REL_12_STABLE [d79f00e82] 2022-07-29 13:30:50 -0400
Branch: REL_11_STABLE [8dea18372] 2022-07-29 13:30:50 -0400
Branch: REL_10_STABLE [e6a48014d] 2022-07-29 13:30:50 -0400
Branch: master [83f1793d6] 2022-08-01 12:22:35 -0400
Branch: REL_15_STABLE [adc3ae6eb] 2022-08-01 12:22:35 -0400
Branch: REL_14_STABLE [d947a8bd5] 2022-08-01 12:22:35 -0400
Branch: REL_13_STABLE [331f8b851] 2022-08-01 12:22:35 -0400
Branch: REL_12_STABLE [5d280bc89] 2022-08-01 12:22:35 -0400
Branch: REL_11_STABLE [51d8b52fc] 2022-08-01 12:22:35 -0400
Branch: REL_10_STABLE [d54fc7e67] 2022-08-01 12:22:35 -0400
-->
     <para>
      Reject <literal>ROW()</literal> expressions and functions
      in <literal>FROM</literal> that have too many columns (Tom Lane)
     </para>

     <para>
      Cases with more than about 1600 columns are unsupported, and
      have always failed at execution.  However, it emerges that some
      earlier code could be driven to assertion failures or crashes by
      queries with more than 32K columns.  Add a parse-time check to
      prevent that.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [c7461fc25] 2022-05-21 14:45:58 -0400
Branch: REL_14_STABLE Release: REL_14_4 [6f7eec119] 2022-05-21 14:45:58 -0400
Branch: REL_13_STABLE [fefd54631] 2022-05-21 14:45:58 -0400
Branch: REL_12_STABLE [bb2c04676] 2022-05-21 14:45:58 -0400
Branch: REL_11_STABLE [f3b8d7244] 2022-05-21 14:45:58 -0400
Branch: REL_10_STABLE [7686403b4] 2022-05-21 14:45:58 -0400
-->
     <para>
      When decompiling a view or rule, show a <command>SELECT</command>
      output column's <literal>AS "?column?"</literal> alias clause
      if it could be referenced elsewhere (Tom Lane)
     </para>

     <para>
      Previously, this auto-generated alias was always hidden; but there
      are corner cases where doing so results in a non-restorable view or
      rule definition.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b9654cece] 2022-07-21 13:56:02 -0400
Branch: REL_15_STABLE [c1d1e8469] 2022-07-21 13:56:05 -0400
Branch: REL_14_STABLE [da9a28fd5] 2022-07-21 13:56:02 -0400
Branch: REL_13_STABLE [5b5d43513] 2022-07-21 13:56:02 -0400
Branch: REL_12_STABLE [b243092a6] 2022-07-21 13:56:02 -0400
Branch: REL_11_STABLE [1078742af] 2022-07-21 13:56:02 -0400
Branch: REL_10_STABLE [6bceacfe8] 2022-07-21 13:56:02 -0400
-->
     <para>
      Fix dumping of a view using a function in <literal>FROM</literal>
      that returns a composite type, when column(s) of the composite type
      have been dropped since the view was made (Tom Lane)
     </para>

     <para>
      This oversight could lead to dump/reload
      or <application>pg_upgrade</application> failures, as the dumped
      view would have too many column aliases for the function.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master Release: REL_15_BR [602986191] 2022-05-20 18:52:55 +0200
Branch: REL_14_STABLE Release: REL_14_4 [58b088a9b] 2022-05-20 18:52:55 +0200
Branch: REL_13_STABLE [3753a169e] 2022-05-20 18:52:55 +0200
Branch: REL_12_STABLE [4492e73a6] 2022-05-20 18:52:55 +0200
Branch: REL_11_STABLE [6c6ea6ea8] 2022-05-20 18:52:55 +0200
Branch: REL_10_STABLE [70f70d7d3] 2022-05-20 18:52:55 +0200
Branch: REL_10_STABLE [8c47622bb] 2022-05-20 19:05:55 +0200
-->
     <para>
      Report implicitly-created operator families to event triggers
      (Masahiko Sawada)
     </para>

     <para>
      If <command>CREATE OPERATOR CLASS</command> results in the implicit
      creation of an operator family, that object was not reported to
      event triggers that should capture such events.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_14_STABLE Release: REL_14_4 [6dced63b4] 2022-05-16 11:26:22 +0900
Branch: REL_13_STABLE [2e9559b30] 2022-05-16 11:26:26 +0900
Branch: REL_12_STABLE [7e59b1219] 2022-05-16 11:26:30 +0900
Branch: REL_11_STABLE [4525151d4] 2022-05-16 11:26:36 +0900
Branch: REL_10_STABLE [60e956eb8] 2022-05-16 11:26:41 +0900
-->
     <para>
      Fix control file updates made when a restartpoint is running during
      promotion of a standby server (Kyotaro Horiguchi)
     </para>

     <para>
      Previously, when the restartpoint completed it could incorrectly
      update the last-checkpoint fields of the control file, potentially
      leading to PANIC and failure to restart if the server crashes before
      the next normal checkpoint completes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_15_BR [f95d53ede] 2022-05-11 11:11:44 +0530
Branch: REL_14_STABLE Release: REL_14_4 [d6da71fa8] 2022-05-11 10:51:04 +0530
Branch: REL_13_STABLE [55558df23] 2022-05-11 10:41:24 +0530
Branch: REL_12_STABLE [f832b5007] 2022-05-11 10:25:56 +0530
Branch: REL_11_STABLE [87c1dd246] 2022-05-11 10:12:23 +0530
Branch: REL_10_STABLE [a4015ec03] 2022-05-11 10:01:35 +0530
-->
     <para>
      Prevent triggering of
      standby's <varname>wal_receiver_timeout</varname> during logical
      replication of large transactions (Wang Wei, Amit Kapila)
     </para>

     <para>
      If a large transaction on the primary server sends no data to the
      standby (perhaps because no table it changes is published), it was
      possible for the standby to timeout.  Fix that by ensuring we send
      keepalive messages periodically in such situations.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [ee7964776] 2022-07-20 09:56:42 +0900
Branch: REL_15_STABLE [286793b98] 2022-07-20 09:56:52 +0900
Branch: REL_14_STABLE [2aedf25eb] 2022-07-20 09:52:11 +0900
Branch: REL_13_STABLE [5630f39b3] 2022-07-20 09:52:23 +0900
Branch: REL_12_STABLE [9fa00e312] 2022-07-20 09:52:29 +0900
Branch: REL_11_STABLE [87e504487] 2022-07-20 09:52:36 +0900
Branch: REL_10_STABLE [dd831afc4] 2022-07-20 09:52:43 +0900
-->
     <para>
      Disallow nested backup operations in logical replication walsenders
      (Fujii Masao)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_15_BR [ac0e2d387] 2022-06-23 09:23:46 +0530
Branch: REL_14_STABLE [3238b5c33] 2022-06-23 09:20:41 +0530
Branch: REL_13_STABLE [3a6ef0cdf] 2022-06-23 09:02:16 +0530
Branch: REL_12_STABLE [9e0d9a24e] 2022-06-23 08:47:15 +0530
Branch: REL_11_STABLE [ed2a7a6bf] 2022-06-23 08:37:40 +0530
Branch: REL_10_STABLE [d873b5a5a] 2022-06-23 08:26:56 +0530
-->
     <para>
      Fix memory leak in logical replication subscribers (Hou Zhijie)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_15_BR [26b3455af] 2022-06-21 08:07:43 +0530
Branch: REL_14_STABLE [52d5ea9ad] 2022-06-21 08:03:30 +0530
Branch: REL_13_STABLE [5f113d60e] 2022-06-21 08:05:31 +0530
Branch: master Release: REL_15_BR [75bfe7434] 2022-06-21 15:39:35 +0530
Branch: REL_14_STABLE [f0022a77d] 2022-06-21 15:30:36 +0530
Branch: REL_13_STABLE [419c72715] 2022-06-21 15:12:52 +0530
-->
     <para>
      Fix logical replication's checking of replica identity when the
      target table is partitioned (Shi Yu, Hou Zhijie)
     </para>

     <para>
      The replica identity columns have to be re-identified for the child
      partition.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_15_BR [b7658c24c] 2022-06-16 08:45:07 +0530
Branch: REL_14_STABLE [0980adfd4] 2022-06-16 08:32:10 +0530
Branch: REL_13_STABLE [1f9a7738e] 2022-06-16 08:24:22 +0530
Branch: master Release: REL_15_BR [5a97b1325] 2022-06-15 09:52:12 +0530
Branch: REL_14_STABLE [d457cb4e8] 2022-06-15 09:59:52 +0530
Branch: REL_13_STABLE [16f5a8da7] 2022-06-15 10:16:35 +0530
-->
     <para>
      Fix failures to update cached schema data in a logical replication
      subscriber after a schema change on the publisher (Shi Yu, Hou
      Zhijie)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [16c80e7d0] 2022-05-31 14:47:44 -0400
Branch: REL_14_STABLE Release: REL_14_4 [c47a55852] 2022-05-31 14:47:44 -0400
Branch: REL_13_STABLE [c73748b68] 2022-05-31 14:47:44 -0400
Branch: REL_12_STABLE [a3faebd6a] 2022-05-31 14:47:44 -0400
Branch: REL_11_STABLE [ae758e603] 2022-05-31 14:47:44 -0400
Branch: REL_10_STABLE [2114910ca] 2022-05-31 14:47:44 -0400
-->
     <para>
      Prevent open-file leak when reading an invalid timezone abbreviation
      file (Kyotaro Horiguchi)
     </para>

     <para>
      Such cases could result in harmless warning messages.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_15_BR [f1431f3bf] 2022-05-28 12:12:40 +0900
Branch: REL_14_STABLE Release: REL_14_4 [fe441a031] 2022-05-28 12:12:46 +0900
Branch: REL_13_STABLE [1e6802990] 2022-05-28 12:12:51 +0900
Branch: REL_12_STABLE [ae236bf66] 2022-05-28 12:12:55 +0900
Branch: REL_11_STABLE [c3db8a2e2] 2022-05-28 12:12:58 +0900
Branch: REL_10_STABLE [1b40ceea2] 2022-05-28 12:13:02 +0900
-->
     <para>
      Allow custom server parameters to have short descriptions that are
      NULL (Steve Chavez)
     </para>

     <para>
      Previously, although extensions could choose to create such
      settings, some code paths would crash while processing them.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [e44dae07f] 2022-08-05 18:00:17 +0200
Branch: REL_15_STABLE [2cff30259] 2022-08-05 18:00:17 +0200
Branch: REL_14_STABLE [541f41d4f] 2022-08-05 18:00:17 +0200
Branch: REL_13_STABLE [de31e6f81] 2022-08-05 18:00:17 +0200
Branch: REL_12_STABLE [49b85e481] 2022-08-05 18:00:17 +0200
Branch: REL_11_STABLE [39e45d3ce] 2022-08-05 18:00:17 +0200
Branch: REL_10_STABLE [e797c7a6f] 2022-08-05 18:00:17 +0200
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [afe58c8b7] 2022-08-07 10:19:40 +0200
Branch: REL_15_STABLE [9c3006000] 2022-08-07 10:19:40 +0200
Branch: REL_14_STABLE [f4beef1c2] 2022-08-07 10:19:40 +0200
Branch: REL_13_STABLE [1626590f2] 2022-08-07 10:19:40 +0200
Branch: REL_12_STABLE [3aafd5da7] 2022-08-07 10:19:40 +0200
Branch: REL_11_STABLE [61904503b] 2022-08-07 10:19:40 +0200
Branch: REL_10_STABLE [8e5874964] 2022-08-07 10:19:40 +0200
-->
     <para>
      Fix WAL consistency checking logic to correctly
      handle <literal>BRIN_EVACUATE_PAGE</literal> flags (Haiyang Wang)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [eed959a45] 2022-07-11 16:43:29 +1200
Branch: REL_15_STABLE [53df1e28d] 2022-07-11 16:01:22 +1200
Branch: REL_14_STABLE [5e7608e81] 2022-07-11 15:47:12 +1200
Branch: REL_13_STABLE [7cdd0c2d7] 2022-07-11 15:48:54 +1200
Branch: REL_12_STABLE [4f88dbac2] 2022-07-11 15:51:47 +1200
Branch: REL_11_STABLE [cd26139a3] 2022-07-11 15:54:24 +1200
-->
     <para>
      Fix erroneous assertion checks in shared hashtable management
      (Thomas Munro)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [604651880] 2022-06-22 12:11:59 -0400
Branch: REL_13_STABLE [cfc86f987] 2022-06-22 12:12:00 -0400
Branch: REL_12_STABLE [293f5c5f4] 2022-06-22 12:12:00 -0400
Branch: REL_11_STABLE [2f6b8c287] 2022-06-22 12:12:00 -0400
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: REL_14_STABLE [8657946d3] 2022-07-18 16:23:48 +0200
Branch: REL_13_STABLE [b2c8d5661] 2022-07-18 19:20:07 +0200
Branch: REL_12_STABLE [9af9e2094] 2022-07-18 19:33:46 +0200
Branch: REL_11_STABLE [6d61aef5d] 2022-07-18 19:38:24 +0200
-->
     <para>
      Arrange to clean up after commit-time errors
      within <function>SPI_commit()</function>, rather than expecting
      callers to do that (Peter Eisentraut, Tom Lane)
     </para>

     <para>
      Proper cleanup is complicated and requires use of low-level
      facilities, so it's not surprising that no known caller got it
      right.  This led to misbehaviors when a PL procedure
      issued <command>COMMIT</command> but a failure occurred (such as a
      deferred constraint check).  To improve matters,
      redefine <function>SPI_commit()</function> as starting a new
      transaction, so that it becomes equivalent
      to <function>SPI_commit_and_chain()</function> except that you get
      default transaction characteristics instead of preserving the prior
      transaction's characteristics.  To make this somewhat transparent
      API-wise, redefine <function>SPI_start_transaction()</function> as a
      no-op.  All known callers of <function>SPI_commit()</function>
      immediately call <function>SPI_start_transaction()</function>, so
      they will not notice any change.  Similar remarks apply
      to <function>SPI_rollback()</function>.
     </para>

     <para>
      Also fix PL/Python, which omitted any handling of such errors at all,
      resulting in jumping out of the Python interpreter.  This is
      reported to crash Python 3.11.  Older Python releases leak some
      memory but seem okay with it otherwise.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [2b65de7fc] 2022-05-26 14:14:05 -0400
Branch: REL_14_STABLE Release: REL_14_4 [b4be4a082] 2022-05-26 14:14:05 -0400
Branch: REL_13_STABLE [9e3dbc6fd] 2022-05-26 14:14:05 -0400
Branch: REL_12_STABLE [01ab9fb7d] 2022-05-26 14:14:05 -0400
Branch: REL_11_STABLE [a44bc8b8f] 2022-05-26 14:14:05 -0400
Branch: REL_10_STABLE [ef54a6576] 2022-05-26 14:14:05 -0400
-->
     <para>
      Remove misguided SSL key file ownership check
      in <application>libpq</application> (Tom Lane)
     </para>

     <para>
      In the previous minor releases, we copied the server's permission
      checking rules for SSL private key files into libpq.  But we should
      not have also copied the server's file-ownership check.  While that
      works in normal use-cases, it can result in an unexpected failure
      for clients running as root, and perhaps in other cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [6d157e7cb] 2022-06-06 11:20:21 -0400
Branch: REL_14_STABLE Release: REL_14_4 [a5dbca460] 2022-06-06 11:20:31 -0400
Branch: REL_13_STABLE [16d68007c] 2022-06-06 11:20:36 -0400
Branch: REL_12_STABLE [02026cadb] 2022-06-06 11:20:41 -0400
Branch: REL_11_STABLE [d82ed5b2f] 2022-06-06 11:20:46 -0400
Branch: REL_10_STABLE [89254606b] 2022-06-06 11:20:52 -0400
-->
     <para>
      Ensure <application>ecpg</application> reports server connection loss
      sanely (Tom Lane)
     </para>

     <para>
      Misprocessing of a libpq-generated error result, such as a report of
      lost connection, would lead to printing <quote>(null)</quote>
      instead of a useful error message; or in older releases it would
      lead to a crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [ba412c905] 2022-06-14 18:16:46 -0400
Branch: REL_14_STABLE [7bc21ed8c] 2022-06-14 18:16:46 -0400
Branch: REL_13_STABLE [12b8fb34a] 2022-06-14 18:16:46 -0400
Branch: REL_12_STABLE [9a3aab0f2] 2022-06-14 18:16:46 -0400
Branch: REL_11_STABLE [f7797747f] 2022-06-14 18:16:46 -0400
Branch: REL_10_STABLE [86258f083] 2022-06-14 18:16:46 -0400
-->
     <para>
      Avoid core dump in <application>ecpglib</application> with
      unexpected orders of operations (Tom Lane)
     </para>

     <para>
      Certain operations such as <command>EXEC SQL PREPARE</command> would
      crash (rather than reporting an error as expected) if called before
      establishing any database connection.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [5633836ef] 2022-07-02 13:00:30 -0700
Branch: REL_15_STABLE [7a28f7cb0] 2022-07-02 13:00:34 -0700
Branch: REL_14_STABLE [5b94e2bd4] 2022-07-02 13:00:34 -0700
Branch: REL_13_STABLE [b4d7e92bd] 2022-07-02 13:00:34 -0700
Branch: REL_12_STABLE [5e0b8f3f4] 2022-07-02 13:00:34 -0700
Branch: REL_11_STABLE [d68b731a1] 2022-07-02 13:00:35 -0700
Branch: REL_10_STABLE [12b2a2369] 2022-07-02 13:00:35 -0700
Branch: master [e2bc24283] 2022-07-02 21:03:19 -0700
Branch: REL_15_STABLE [8533eb181] 2022-07-02 21:03:22 -0700
Branch: REL_14_STABLE [463a841d7] 2022-07-02 21:03:22 -0700
Branch: REL_13_STABLE [97b005f3f] 2022-07-02 21:03:23 -0700
Branch: REL_12_STABLE [a4240139f] 2022-07-02 21:03:23 -0700
Branch: REL_11_STABLE [1cad30e3b] 2022-07-02 21:03:24 -0700
Branch: REL_10_STABLE [f5e4d64bb] 2022-07-02 21:03:24 -0700
-->
     <para>
      In <application>ecpglib</application>, avoid
      redundant <function>newlocale()</function> calls (Noah Misch)
     </para>

     <para>
      Allocate a C locale object once per process when first connecting,
      rather than creating and freeing locale objects once per query.
      This mitigates a libc memory leak on AIX, and may offer some
      performance benefit everywhere.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [21267b647] 2022-07-10 16:52:38 +1200
Branch: REL_15_STABLE [31b485f88] 2022-07-10 16:53:05 +1200
Branch: REL_14_STABLE [ab7fef0ac] 2022-07-10 16:53:18 +1200
Branch: REL_13_STABLE [e5b5b4448] 2022-07-10 16:53:39 +1200
Branch: REL_12_STABLE [09224a35c] 2022-07-10 16:54:09 +1200
Branch: REL_11_STABLE [21ed12b14] 2022-07-10 16:55:18 +1200
Branch: REL_10_STABLE [7c5953b7b] 2022-07-10 16:57:04 +1200
-->
     <para>
      In <application>psql</application>'s <command>\watch</command>
      command, echo a newline after cancellation with control-C
      (Pavel Stehule)
     </para>

     <para>
      This prevents libedit (and possibly also libreadline) from becoming
      confused about which column the cursor is in.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [8b1ec7d29] 2022-08-01 16:38:23 +0900
Branch: REL_15_STABLE [07abcd9ab] 2022-08-01 16:39:16 +0900
Branch: REL_14_STABLE [523926dea] 2022-08-01 16:39:27 +0900
Branch: REL_13_STABLE [aadaaeff4] 2022-08-01 16:39:30 +0900
Branch: REL_12_STABLE [24872bbf9] 2022-08-01 16:39:33 +0900
-->
     <para>
      Fix possible report of wrong error condition
      after <function>clone()</function> failure
      in <application>pg_upgrade</application>
      with <option>--clone</option> option (Justin Pryzby)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c67c2e2a2] 2022-08-02 18:05:38 -0400
Branch: REL_15_STABLE [82ebc70d1] 2022-08-02 18:05:34 -0400
Branch: REL_14_STABLE [17fd203b4] 2022-08-02 18:05:34 -0400
Branch: REL_13_STABLE [6b67db10c] 2022-08-02 18:05:34 -0400
Branch: REL_12_STABLE [6608a4305] 2022-08-02 18:05:34 -0400
Branch: REL_11_STABLE [06f6a07ba] 2022-08-02 18:05:34 -0400
Branch: REL_10_STABLE [dd414bf4e] 2022-08-02 18:05:34 -0400
-->
     <para>
      Fix <filename>contrib/pg_stat_statements</filename> to avoid
      problems with very large query-text files on 32-bit platforms
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0a7ccee8f] 2022-07-17 17:27:50 -0400
Branch: REL_15_STABLE [b8032f481] 2022-07-17 17:27:50 -0400
Branch: REL_14_STABLE [810bcbd38] 2022-07-17 17:27:50 -0400
Branch: REL_13_STABLE [6230bd7df] 2022-07-17 17:27:50 -0400
Branch: REL_12_STABLE [288e499ba] 2022-07-17 17:27:50 -0400
Branch: REL_11_STABLE [94bcb48ab] 2022-07-17 17:27:50 -0400
Branch: REL_10_STABLE [26c9e1bd8] 2022-07-17 17:27:51 -0400
-->
     <para>
      Ensure that <filename>contrib/postgres_fdw</filename> sends
      constants of <type>regconfig</type> and other <type>reg*</type>
      types with proper schema qualification (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [4518c798b] 2022-07-14 18:01:27 +1200
Branch: REL_15_STABLE [c4a617ea1] 2022-07-14 18:00:58 +1200
Branch: REL_14_STABLE [2019e6ecf] 2022-07-14 17:48:32 +1200
Branch: REL_13_STABLE [e73fe6e82] 2022-07-14 14:32:48 +1200
Branch: REL_12_STABLE [ff78bf796] 2022-07-14 14:26:49 +1200
Branch: REL_11_STABLE [39683c69a] 2022-07-14 14:23:03 +1200
Branch: REL_10_STABLE [53cfe403c] 2022-07-14 10:50:13 +1200
Branch: master [80845b7c0] 2022-07-15 02:00:09 +1200
Branch: REL_15_STABLE [a715c2004] 2022-07-15 02:00:35 +1200
Branch: REL_14_STABLE [838364559] 2022-07-15 02:02:28 +1200
Branch: REL_13_STABLE [17aa39da5] 2022-07-15 02:04:53 +1200
Branch: REL_12_STABLE [a05f40ef8] 2022-07-15 02:06:01 +1200
Branch: REL_11_STABLE [74a9ee034] 2022-07-15 02:07:15 +1200
Branch: REL_10_STABLE [e26024bea] 2022-07-15 02:08:27 +1200
Branch: master [3b8d23a3e] 2022-07-16 12:22:42 +1200
Branch: REL_15_STABLE [91377a455] 2022-07-16 12:23:03 +1200
Branch: REL_14_STABLE [c412c60b9] 2022-07-16 12:23:14 +1200
Branch: REL_13_STABLE [c75b6b454] 2022-07-16 12:23:24 +1200
Branch: REL_12_STABLE [1661c40b9] 2022-07-16 12:23:34 +1200
Branch: REL_11_STABLE [3f2344d4a] 2022-07-16 12:23:43 +1200
Branch: REL_10_STABLE [d3b0884c0] 2022-07-16 12:23:52 +1200
-->
     <para>
      Block signals while allocating dynamic shared memory on Linux
      (Thomas Munro)
     </para>

     <para>
      This avoids problems when a signal
      interrupts <function>posix_fallocate()</function>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [389869af5] 2022-07-01 14:17:54 +1200
Branch: REL_15_STABLE [fef8c7a0c] 2022-07-01 13:15:17 +1200
Branch: REL_14_STABLE [fb81a93a6] 2022-07-01 13:16:27 +1200
Branch: REL_13_STABLE [b436047dc] 2022-07-01 14:03:48 +1200
Branch: REL_12_STABLE [f7b69b1e3] 2022-07-01 13:26:50 +1200
Branch: REL_11_STABLE [facfd0467] 2022-07-01 13:21:28 +1200
Branch: REL_10_STABLE [22b9afaf5] 2022-07-01 13:19:06 +1200
-->
     <para>
      Detect unexpected <literal>EEXIST</literal> error
      from <function>shm_open()</function> (Thomas Munro)
     </para>

     <para>
      This avoids a possible crash on Solaris.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [eb39610f8] 2022-06-01 16:15:47 -0400
Branch: REL_14_STABLE Release: REL_14_4 [1072e4c45] 2022-06-01 16:15:47 -0400
Branch: REL_13_STABLE [eeac7dd9f] 2022-06-01 16:15:47 -0400
Branch: REL_12_STABLE [c08538734] 2022-06-01 16:15:47 -0400
Branch: REL_11_STABLE [b5265196e] 2022-06-01 16:15:47 -0400
Branch: REL_10_STABLE [d5e1d5ed9] 2022-06-01 16:15:47 -0400
Branch: REL9_6_STABLE [d4c161842] 2022-06-01 16:15:47 -0400
Branch: REL9_5_STABLE [9fdeae848] 2022-06-01 16:15:47 -0400
Branch: REL9_4_STABLE [b53780e1b] 2022-06-01 16:15:47 -0400
Branch: REL9_3_STABLE [a3b685fdd] 2022-06-01 16:15:47 -0400
Branch: REL9_2_STABLE [6f9ea6cf3] 2022-06-01 16:15:47 -0400
-->
     <para>
      Adjust PL/Perl test case so it will work under Perl 5.36
      (Dagfinn Ilmari Mannsåker)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_15_BR [aff45c879] 2022-05-10 18:42:02 -0400
Branch: REL_14_STABLE Release: REL_14_4 [12736e7dc] 2022-05-10 18:42:02 -0400
Branch: REL_13_STABLE [af9b96767] 2022-05-10 18:42:02 -0400
Branch: REL_12_STABLE [8ed13fb93] 2022-05-10 18:42:02 -0400
Branch: REL_11_STABLE [36d76da81] 2022-05-10 18:42:02 -0400
Branch: REL_10_STABLE [c61f36d99] 2022-05-10 18:42:02 -0400
-->
     <para>
      Avoid incorrectly using an
      out-of-date <application>libldap_r</application> library when
      multiple <productname>OpenLDAP</productname> installations are
      present while building <productname>PostgreSQL</productname>
      (Tom Lane)
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-7">
  <title>Release 13.7</title>

  <formalpara>
  <title>Release date:</title>
  <para>2022-05-12</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.6.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.7</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you have any GiST indexes on columns of type
    <type>ltree</type> (supplied by the <filename>contrib/ltree</filename>
    extension), you should re-index them after updating.
    See the second changelog entry below.
   </para>

   <para>
    Also, if you are upgrading from a version earlier than 13.6,
    see <xref linkend="release-13-6"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [a117cebd6] 2022-05-09 08:35:08 -0700
Branch: REL_14_STABLE [ab49ce7c3] 2022-05-09 08:35:12 -0700
Branch: REL_13_STABLE [35edcc0ce] 2022-05-09 08:35:12 -0700
Branch: REL_12_STABLE [7f098f7b5] 2022-05-09 08:35:12 -0700
Branch: REL_11_STABLE [48ca2904c] 2022-05-09 08:35:13 -0700
Branch: REL_10_STABLE [ef792f785] 2022-05-09 08:35:13 -0700
Author: Noah Misch <noah@leadboat.com>
Branch: master [0abc1a059] 2022-05-09 08:35:08 -0700
Branch: REL_14_STABLE [677a49478] 2022-05-09 08:35:12 -0700
Branch: REL_13_STABLE [88743d581] 2022-05-09 08:35:12 -0700
Branch: REL_12_STABLE [880511cb0] 2022-05-09 08:35:12 -0700
Branch: REL_11_STABLE [34ff15660] 2022-05-09 08:35:13 -0700
Branch: REL_10_STABLE [f26d57028] 2022-05-09 08:35:13 -0700
-->
     <para>
      Confine additional operations within <quote>security restricted
      operation</quote> sandboxes (Sergey Shinderuk, Noah Misch)
     </para>

     <para>
      Autovacuum, <command>CLUSTER</command>, <command>CREATE
      INDEX</command>, <command>REINDEX</command>, <command>REFRESH
      MATERIALIZED VIEW</command>,
      and <application>pg_amcheck</application> activated
      the <quote>security restricted operation</quote> protection
      mechanism too late, or even not at all in some code paths.
      A user having permission to create non-temporary objects within a
      database could define an object that would execute arbitrary SQL
      code with superuser permissions the next time that autovacuum
      processed the object, or that some superuser ran one of the affected
      commands against it.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Alexander Lakhin for reporting this problem.
      (CVE-2022-1552)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [7e74aafc4] 2022-03-16 11:41:18 +0300
Branch: REL_14_STABLE [7d30f59da] 2022-03-16 11:41:30 +0300
Branch: REL_13_STABLE [bad202c61] 2022-03-16 11:41:34 +0300
-->
     <para>
      Fix default signature length for <literal>gist_ltree_ops</literal>
      indexes (Tomas Vondra, Alexander Korotkov)
     </para>

     <para>
      The default signature length (hash size) for GiST indexes
      on <type>ltree</type> columns was accidentally changed while
      upgrading that operator class to support operator class parameters.
      If any operations had been done on such an index without first
      upgrading the <literal>ltree</literal> extension to version 1.2,
      they were done assuming that the signature length was 28 bytes
      rather than the intended 8.  This means it is very likely that such
      indexes are now corrupt.  For safety we recommend re-indexing all
      GiST indexes on <type>ltree</type> columns after installing this
      update.  (Note that GiST indexes on <type>ltree[]</type>
      columns, that is arrays of <type>ltree</type>, are not affected.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ec62cb0aa] 2022-03-17 18:18:05 -0400
Branch: REL_14_STABLE [1d072bd20] 2022-03-17 18:18:05 -0400
Branch: REL_13_STABLE [5e144cc89] 2022-03-17 18:18:05 -0400
Branch: REL_12_STABLE [1f5ef5ae0] 2022-03-17 18:18:05 -0400
Branch: REL_11_STABLE [13b54d1e0] 2022-03-17 18:18:05 -0400
Branch: REL_10_STABLE [205214c8b] 2022-03-17 18:18:05 -0400
-->
     <para>
      Stop using query-provided column aliases for the columns of
      whole-row variables that refer to plain tables (Tom Lane)
     </para>

     <para>
      The column names in tuples produced by a whole-row variable (such
      as <literal>tbl.*</literal> in contexts other than the top level of
      a <literal>SELECT</literal> list) are now always those of the
      associated named composite type, if there is one.  We'd previously
      attempted to make them track any column aliases that had been
      applied to the <literal>FROM</literal> entry the variable refers to.
      But that's semantically dubious, because really then the output of
      the variable is not at all of the composite type it claims to be.
      Previous attempts to deal with that inconsistency had bad results up
      to and including storing unreadable data on disk, so just give up on
      the whole idea.
     </para>

     <para>
      In cases where it's important to be able to relabel such columns,
      a workaround is to introduce an extra level of
      sub-<literal>SELECT</literal>, so that the whole-row variable is
      referring to the sub-<literal>SELECT</literal>'s output and not to a
      plain table.  Then the variable is of type <type>record</type>
      to begin with and there's no issue.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [068739fb4] 2022-03-18 16:01:42 -0400
Branch: REL_14_STABLE [ae8ec7feb] 2022-03-18 16:01:42 -0400
Branch: REL_13_STABLE [88ae77588] 2022-03-18 16:01:42 -0400
Branch: REL_12_STABLE [840729fd1] 2022-03-18 16:01:42 -0400
Branch: REL_11_STABLE [84f3ecdaa] 2022-03-18 16:01:42 -0400
Branch: REL_10_STABLE [e6fd4a3da] 2022-03-18 16:01:42 -0400
-->
     <para>
      Fix incorrect output for types <type>timestamptz</type>
      and <type>timetz</type> in <function>table_to_xmlschema()</function>
      and allied functions (Renan Soares Lopes)
     </para>

     <para>
      The xmlschema output for these types included a malformed regular
      expression.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [fe20afaee] 2022-05-09 14:15:37 -0400
Branch: REL_14_STABLE [ab2f78392] 2022-05-09 14:15:37 -0400
Branch: REL_13_STABLE [91a3a74c6] 2022-05-09 14:15:37 -0400
Branch: REL_12_STABLE [90e52884e] 2022-05-09 14:15:37 -0400
Branch: REL_11_STABLE [539f8c563] 2022-05-09 14:15:37 -0400
Branch: REL_10_STABLE [4eabaffca] 2022-05-09 14:15:37 -0400
-->
     <para>
      Avoid core dump in parser for a <literal>VALUES</literal> clause with
      zero columns (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2591ee8ec] 2022-03-21 17:44:29 -0400
Branch: REL_14_STABLE [48b6035f0] 2022-03-21 17:44:29 -0400
Branch: REL_13_STABLE [dfefe38fb] 2022-03-21 17:44:29 -0400
Branch: REL_12_STABLE [69c88e2fb] 2022-03-21 17:44:29 -0400
Branch: REL_11_STABLE [5de244196] 2022-03-21 17:44:29 -0400
Branch: REL_10_STABLE [2afa031ac] 2022-03-21 17:44:29 -0400
-->
     <para>
      Fix planner errors for <function>GROUPING()</function> constructs
      that reference outer query levels (Richard Guo, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e5691cc91] 2022-02-11 15:24:02 -0500
Branch: REL_14_STABLE [277e744ae] 2022-02-11 15:23:52 -0500
Branch: REL_13_STABLE [0778b24ce] 2022-02-11 15:23:52 -0500
Branch: REL_12_STABLE [32e801676] 2022-02-11 15:23:52 -0500
Branch: REL_11_STABLE [14ee565f3] 2022-02-11 15:23:52 -0500
Branch: REL_10_STABLE [b6f869bee] 2022-02-11 15:23:52 -0500
-->
     <para>
      Fix plan generation for index-only scans on indexes with
      both returnable and non-returnable columns (Tom Lane)
     </para>

     <para>
      The previous coding could try to read non-returnable columns
      in addition to the returnable ones.  This was fairly harmless
      because it didn't actually do anything with the bogus values,
      but it fell foul of a recently-added error check that rejected
      such a plan.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7b7ed046c] 2022-04-13 13:35:07 -0400
Branch: REL_14_STABLE [c590e514a] 2022-04-13 13:35:02 -0400
Branch: REL_13_STABLE [44096c31e] 2022-04-13 13:35:02 -0400
Branch: REL_12_STABLE [e0ed20d0b] 2022-04-13 13:35:02 -0400
-->
     <para>
      Avoid accessing a no-longer-pinned shared buffer while attempting
      to lock an outdated tuple during EvalPlanQual (Tom Lane)
     </para>

     <para>
      The code would touch the buffer a couple more times after releasing
      its pin.  In theory another process could recycle the buffer (or
      more likely, try to defragment its free space) as soon as the pin is
      gone, probably leading to failure to find the newer version of the
      tuple.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [3f74daa8d] 2022-02-14 04:17:04 +0300
Branch: REL_14_STABLE [c76665edc] 2022-02-14 03:32:31 +0300
Branch: REL_13_STABLE [ac2303aa0] 2022-02-14 03:32:34 +0300
Branch: REL_12_STABLE [7a12a9e3c] 2022-02-14 03:32:39 +0300
Branch: REL_11_STABLE [0d554775b] 2022-02-14 04:04:19 +0300
Branch: REL_10_STABLE [2e9033a54] 2022-02-14 04:04:28 +0300
-->
     <para>
      Fix query-lifespan memory leak in an IndexScan node that is
      performing reordering (Aliaksandr Kalenik)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [344a225cb] 2022-04-19 23:03:59 -0400
Branch: REL_14_STABLE [08a9e7a8c] 2022-04-19 23:03:59 -0400
Branch: REL_13_STABLE [f583633bc] 2022-04-19 23:03:59 -0400
Branch: REL_12_STABLE [481a99811] 2022-04-19 23:03:59 -0400
Branch: REL_11_STABLE [9130f8cbb] 2022-04-19 23:03:59 -0400
Branch: REL_10_STABLE [409bcfda6] 2022-04-19 23:03:59 -0400
-->
     <para>
      Fix <command>ALTER FUNCTION</command> to support changing a
      function's parallelism property and
      its <literal>SET</literal>-variable list in the same command (Tom
      Lane)
     </para>

     <para>
      The parallelism property change was lost if the same command also
      updated the function's <literal>SET</literal> clause.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [36d4efe77] 2022-04-18 12:16:45 -0400
Branch: REL_14_STABLE [e805735a8] 2022-04-18 12:16:45 -0400
Branch: REL_13_STABLE [69cefb3fb] 2022-04-18 12:16:45 -0400
Branch: REL_12_STABLE [0795da869] 2022-04-18 12:16:45 -0400
-->
     <para>
      Fix bogus errors from attempts to alter system columns of tables
      (Tom Lane)
     </para>

     <para>
      The system should just tell you that you can't do it, but sometimes
      it would report <quote>no owned sequence found</quote> instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [8ab0ebb9a] 2022-04-20 17:17:43 -0700
Branch: REL_14_STABLE [e4521841a] 2022-04-20 17:17:41 -0700
Branch: REL_13_STABLE [1272630a2] 2022-04-20 17:17:39 -0700
Branch: REL_12_STABLE [5487585e3] 2022-04-20 17:17:37 -0700
Branch: REL_11_STABLE [adb2d84fc] 2022-04-20 17:17:35 -0700
Branch: REL_10_STABLE [a903895b3] 2022-04-20 17:17:33 -0700
-->
     <para>
      Fix mis-sorting of table rows when <command>CLUSTER</command>ing
      using an index whose leading key is an expression (Peter Geoghegan,
      Thomas Munro)
     </para>

     <para>
      The table would be rebuilt with the correct data, but in an order
      having little to do with the index order.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7b6ec8653] 2022-03-21 12:22:13 -0400
Branch: REL_14_STABLE [05ccf974c] 2022-03-21 12:22:13 -0400
Branch: REL_13_STABLE [2241e5ced] 2022-03-21 12:22:13 -0400
Branch: REL_12_STABLE [d8d378d51] 2022-03-21 12:22:13 -0400
Branch: REL_11_STABLE [b8ae17fd9] 2022-03-21 12:22:13 -0400
-->
     <para>
      Fix risk of deadlock failures while dropping a partitioned index
      (Jimmy Yih, Gaurab Dey, Tom Lane)
     </para>

     <para>
      Ensure that the required table and index locks are taken in the
      standard order (parents before children, tables before indexes).
      The previous coding for <command>DROP INDEX</command> did it
      differently, and so could deadlock against concurrent queries taking
      these locks in the standard order.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [46d9bfb0a] 2022-03-16 17:20:24 +1300
Branch: REL_14_STABLE [26e007939] 2022-03-16 17:20:50 +1300
Branch: REL_13_STABLE [51e760e5a] 2022-03-16 17:21:19 +1300
Branch: REL_12_STABLE [c918f07dd] 2022-03-16 17:21:46 +1300
Branch: REL_11_STABLE [ca522c60a] 2022-03-16 17:38:55 +1300
Branch: REL_10_STABLE [fe197872c] 2022-03-16 17:41:31 +1300
-->
     <para>
      Fix race condition between <command>DROP TABLESPACE</command> and
      checkpointing (Nathan Bossart)
     </para>

     <para>
      The checkpoint forced by <command>DROP TABLESPACE</command> could
      sometimes fail to remove all dead files from the tablespace's
      directory, leading to a bogus <quote>tablespace is not empty</quote>
      error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master [412ad7a55] 2022-03-24 14:52:28 -0400
Branch: REL_14_STABLE [bbace5697] 2022-03-24 14:32:48 -0400
Branch: REL_13_STABLE [1ce14b6b2] 2022-03-24 14:36:06 -0400
Branch: REL_12_STABLE [3821d66a7] 2022-03-24 14:38:51 -0400
Branch: REL_11_STABLE [118f1a332] 2022-03-24 14:49:08 -0400
Branch: REL_10_STABLE [57f618310] 2022-03-24 14:50:06 -0400
Author: Robert Haas <rhaas@postgresql.org>
Branch: REL_14_STABLE [10520f434] 2022-04-14 11:10:07 -0400
Branch: REL_13_STABLE [d18c913b7] 2022-04-14 11:10:11 -0400
Branch: REL_12_STABLE [68e605b9e] 2022-04-14 11:10:13 -0400
Branch: REL_11_STABLE [6270ee445] 2022-04-14 11:10:16 -0400
Branch: REL_10_STABLE [48b398943] 2022-04-14 11:10:18 -0400
-->
     <para>
      Fix possible trouble in crash recovery after
      a <command>TRUNCATE</command> command that overlaps a checkpoint
      (Kyotaro Horiguchi, Heikki Linnakangas, Robert Haas)
     </para>

     <para>
      <command>TRUNCATE</command> must ensure that the table's disk file
      is truncated before the checkpoint is allowed to complete.
      Otherwise, replay starting from that checkpoint might find
      unexpected data in the supposedly-removed pages, possibly causing
      replay failure.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [7c38ef2a5] 2022-02-21 08:57:34 -0800
Branch: REL_14_STABLE [7bbfe5994] 2022-02-21 09:57:05 -0800
Branch: REL_13_STABLE [c2551483e] 2022-02-21 08:59:30 -0800
Branch: REL_12_STABLE [0033fc63f] 2022-02-21 08:59:32 -0800
Branch: REL_11_STABLE [3faa21bb7] 2022-02-21 08:59:34 -0800
Branch: REL_10_STABLE [cebc54b90] 2022-02-21 08:59:36 -0800
-->
     <para>
      Fix unsafe toast-data accesses during temporary object cleanup
      (Andres Freund)
     </para>

     <para>
      Temporary-object deletion during server process exit could fail
      with <quote>FATAL: cannot fetch toast data without an active
      snapshot</quote>.  This was usually harmless since the next use of
      that temporary schema would clean up successfully.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [3390ef1b7] 2022-03-16 15:35:16 +1300
Branch: REL_14_STABLE [1396b5c6e] 2022-03-16 15:35:42 +1300
Branch: REL_13_STABLE [cfdb303be] 2022-03-16 15:37:15 +1300
Branch: REL_12_STABLE [368ffdeee] 2022-03-16 15:38:13 +1300
-->
     <para>
      Improve wait logic in RegisterSyncRequest (Thomas Munro)
     </para>

     <para>
      If we run out of space in the checkpointer sync request queue (which
      is hopefully rare on real systems, but is common when testing with a
      very small buffer pool), we wait for it to drain.  While waiting, we
      should report that as a wait event so that users know what is going
      on, and also watch for postmaster death, since otherwise the loop might
      never terminate if the checkpointer has already exited.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [9d92582ab] 2022-03-23 18:22:10 +0100
Branch: REL_14_STABLE [caaeb88ff] 2022-03-23 18:22:10 +0100
Branch: REL_13_STABLE [98eb3e06c] 2022-03-23 18:22:10 +0100
Branch: REL_12_STABLE [c714ebd0e] 2022-03-23 18:22:10 +0100
Branch: REL_11_STABLE [199cd7b59] 2022-03-23 18:22:10 +0100
Branch: REL_10_STABLE [9ade3c09a] 2022-03-23 18:22:10 +0100
-->
     <para>
      Fix <quote>PANIC: xlog flush request is not satisfied</quote>
      failure during standby promotion when there is a missing WAL
      continuation record (Sami Imseih)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [8f1537d10] 2022-05-02 18:25:00 -0700
Branch: REL_14_STABLE [9ab3b2bdb] 2022-05-02 18:25:59 -0700
Branch: REL_13_STABLE [57c5ad168] 2022-05-02 18:28:10 -0700
Branch: REL_12_STABLE [edfc03ec9] 2022-05-02 18:29:52 -0700
Branch: REL_11_STABLE [9cda785b4] 2022-05-02 18:30:15 -0700
Branch: REL_10_STABLE [cbc47ad7e] 2022-05-02 18:30:38 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: REL_14_STABLE [f74496dd6] 2022-05-02 18:26:09 -0700
Branch: REL_13_STABLE [0446d3bf3] 2022-05-02 18:29:35 -0700
Branch: REL_12_STABLE [a5ede1391] 2022-05-02 18:29:52 -0700
Branch: REL_11_STABLE [25d5494e2] 2022-05-02 18:30:15 -0700
Branch: REL_10_STABLE [b1f35a36e] 2022-05-02 18:30:38 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: REL_14_STABLE [5ab8e8014] 2022-05-02 18:09:42 -0700
Branch: REL_13_STABLE [90abe1e17] 2022-05-02 18:09:43 -0700
Branch: REL_12_STABLE [5c8b14a71] 2022-05-02 18:09:43 -0700
Branch: REL_11_STABLE [2adb8debe] 2022-05-02 18:09:44 -0700
Branch: REL_10_STABLE [e8a0cf9b2] 2022-05-02 18:09:44 -0700
-->
     <para>
      Fix possibility of self-deadlock in hot standby conflict handling
      (Andres Freund)
     </para>

     <para>
      With unlucky timing, the WAL-applying process could get stuck
      while waiting for some other process to release a buffer lock.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [c91f71b9d] 2022-03-16 18:05:58 +0100
Branch: REL_14_STABLE [677a1dc0c] 2022-03-16 18:06:27 +0100
Branch: REL_13_STABLE [27fafee72] 2022-03-16 18:14:33 +0100
-->
     <para>
      Fix possible mis-identification of the correct ancestor relation
      to publish logical replication changes through (Tomas Vondra, Hou
      zj, Amit Kapila)
     </para>

     <para>
      If <varname>publish_via_partition_root</varname> is enabled, and
      there are multiple publications naming different ancestors of the
      currently-modified relation, the wrong ancestor might be chosen for
      reporting the change.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [dd4ab6fd6] 2022-04-19 08:49:49 +0530
Branch: REL_14_STABLE [c9dea58e2] 2022-04-19 08:54:37 +0530
Branch: REL_13_STABLE [82d4a17a1] 2022-04-19 09:08:05 +0530
Branch: REL_12_STABLE [59348fbde] 2022-04-19 09:18:44 +0530
Branch: REL_11_STABLE [a90de822e] 2022-04-19 09:29:34 +0530
Branch: REL_10_STABLE [be46985be] 2022-04-19 09:38:25 +0530
-->
     <para>
      Ensure that logical replication apply workers can be restarted even
      when we're up against
      the <varname>max_sync_workers_per_subscription</varname> limit
      (Amit Kapila)
     </para>

     <para>
      Faulty coding of the limit check caused a restarted worker to exit
      immediately, leaving fewer workers than there should be.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [5e01001ff] 2022-02-14 08:55:58 +0530
Branch: REL_14_STABLE [04645bbca] 2022-02-14 08:07:46 +0530
Branch: REL_13_STABLE [caa231be9] 2022-02-14 08:24:44 +0530
Branch: REL_12_STABLE [ce349cf17] 2022-02-14 08:27:56 +0530
Branch: REL_11_STABLE [1cd5802ac] 2022-02-14 08:37:23 +0530
Branch: REL_10_STABLE [b5e060473] 2022-02-14 08:45:54 +0530
-->
     <para>
      Include unchanged replica identity key columns in the WAL log for an
      update, if they are stored out-of-line (Dilip Kumar, Amit Kapila)
     </para>

     <para>
      Otherwise subscribers cannot see the values and will fail to
      replicate the update.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0fb6954aa] 2022-03-27 12:57:46 -0400
Branch: REL_14_STABLE [3f7a59c59] 2022-03-27 12:57:52 -0400
Branch: REL_13_STABLE [9016a2a3d] 2022-03-27 12:57:57 -0400
-->
     <para>
      Cope correctly with platforms that have no support for altering the
      server process's display in <application>ps(1)</application> (Andrew
      Dunstan)
     </para>

     <para>
      Few platforms are like this (the only supported one is Cygwin), so
      we'd managed not to notice that refactoring introduced a potential
      memory clobber.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [638300fef] 2022-02-25 17:40:43 -0500
Branch: REL_14_STABLE [ac910bb23] 2022-02-25 17:40:43 -0500
Branch: REL_13_STABLE [9b2d762a2] 2022-02-25 17:40:44 -0500
Branch: REL_12_STABLE [0f7b62f29] 2022-02-25 17:40:45 -0500
Branch: REL_11_STABLE [31befa6be] 2022-02-25 17:40:45 -0500
Branch: REL_10_STABLE [4936747c4] 2022-02-25 17:40:21 -0500
-->
     <para>
      Disallow execution of SPI functions during PL/Perl function
      compilation (Tom Lane)
     </para>

     <para>
      Perl can be convinced to execute user-defined code during compilation
      of a PL/Perl function.  However, it's not okay for such code to try
      to invoke SQL operations via SPI.  That results in a crash, and if
      it didn't crash it would be a security hazard, because we really
      don't want code execution during function validation.  Put in a
      check to give a friendlier error message instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a59c79564] 2022-02-28 14:12:52 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [50f03473e] 2022-03-02 11:29:11 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [2a1f84636] 2022-03-02 11:57:02 -0500
Branch: REL_13_STABLE [6599d8f12] 2022-03-02 11:57:02 -0500
Branch: REL_12_STABLE [72918ea86] 2022-03-02 11:57:02 -0500
Branch: REL_11_STABLE [5bb3d91ea] 2022-03-02 11:57:02 -0500
Branch: REL_10_STABLE [9050999ef] 2022-03-02 11:57:02 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [878e64d0f] 2022-03-31 11:24:26 -0400
Branch: REL_14_STABLE [402279afe] 2022-03-31 11:24:26 -0400
Branch: REL_13_STABLE [fb1d7f451] 2022-03-31 11:24:26 -0400
Branch: REL_12_STABLE [fcaf7d725] 2022-03-31 11:24:26 -0400
Branch: REL_11_STABLE [143043191] 2022-03-31 11:24:26 -0400
Branch: REL_10_STABLE [a6bd1f0ee] 2022-03-31 11:24:26 -0400
-->
     <para>
      Make <application>libpq</application> accept root-owned SSL private
      key files (David Steele)
     </para>

     <para>
      This change synchronizes <application>libpq</application>'s rules
      for safe ownership and permissions of SSL key files with the rules
      the server has used since release 9.6.  Namely, in addition to the
      current rules, allow the case where the key file is owned by root
      and has permissions <literal>rw-r-----</literal> or less.  This is
      helpful for system-wide management of key files.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [335fa5a26] 2022-02-12 13:23:20 -0500
Branch: REL_14_STABLE [ae27b1acc] 2022-02-12 13:23:20 -0500
Branch: REL_13_STABLE [51ee561f5] 2022-02-12 13:23:20 -0500
Branch: REL_12_STABLE [c9d35dc7f] 2022-02-12 13:23:20 -0500
-->
     <para>
      Fix behavior of <application>libpq</application>'s
      <function>PQisBusy()</function> function after a connection failure
      (Tom Lane)
     </para>

     <para>
      If we'd detected a write failure, <function>PQisBusy()</function>
      would always return true, which is the wrong thing: we want input
      processing to carry on normally until we've read whatever is
      available from the server.  The practical effect of this error is
      that applications using <application>libpq</application>'s
      async-query API would typically detect connection loss only
      when <function>PQconsumeInput()</function> returns a hard failure.
      With this fix, a connection loss will normally be reported via an
      error <structname>PGresult</structname> object, which is a much
      cleaner behavior for most applications.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a745b9365] 2022-02-10 16:49:39 -0500
Branch: REL_14_STABLE [1e8c5cf7c] 2022-02-10 16:49:39 -0500
Branch: REL_13_STABLE [d0e1fd958] 2022-02-10 16:49:39 -0500
Branch: REL_12_STABLE [61c20a5ea] 2022-02-10 16:49:39 -0500
Branch: REL_11_STABLE [69cc15c31] 2022-02-10 16:49:39 -0500
Branch: REL_10_STABLE [34523933b] 2022-02-10 16:49:39 -0500
-->
     <para>
      Make <application>pg_ctl</application> recheck postmaster aliveness
      while waiting for stop/restart/promote actions (Tom Lane)
     </para>

     <para>
      <application>pg_ctl</application> would verify that the postmaster
      is alive as a side-effect of sending the stop or promote signal, but
      then it just naively waited to see the on-disk state change.  If the
      postmaster died uncleanly without having removed its PID file or
      updated the control file, <application>pg_ctl</application> would
      wait until timeout.  Instead make it recheck every so often that the
      postmaster process is still there.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [cd83cb953] 2022-02-25 10:30:05 -0800
Branch: REL_14_STABLE [9ff7fd906] 2022-02-25 10:31:16 -0800
Branch: REL_13_STABLE [0b1020a96] 2022-02-25 10:32:38 -0800
Branch: REL_12_STABLE [5407241a8] 2022-02-25 10:34:38 -0800
Branch: REL_11_STABLE [51c341656] 2022-02-25 10:40:32 -0800
Author: Andres Freund <andres@anarazel.de>
Branch: master [264d28492] 2022-03-27 18:13:50 -0700
Branch: REL_14_STABLE [6839aa7a6] 2022-03-27 18:15:10 -0700
Branch: REL_13_STABLE [344d89abf] 2022-03-27 18:15:14 -0700
Branch: REL_12_STABLE [5ebd262dc] 2022-03-27 18:15:15 -0700
Branch: REL_11_STABLE [7d935bdf7] 2022-03-27 18:15:17 -0700
-->
     <para>
      Fix error handling in <application>pg_waldump</application> (Kyotaro
      Horiguchi, Andres Freund)
     </para>

     <para>
      While trying to read a WAL file to determine the WAL segment size,
      <application>pg_waldump</application> would report an incorrect
      error for the case of a too-short file.  In addition, the file name
      reported in this and related error messages could be garbage.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [cd4868a57] 2022-04-14 15:08:03 +0900
Branch: REL_14_STABLE [df6bbe73b] 2022-04-14 15:09:26 +0900
Branch: REL_13_STABLE [2275d044d] 2022-04-14 15:09:36 +0900
Branch: REL_12_STABLE [5378d55cb] 2022-04-14 15:09:39 +0900
Branch: REL_11_STABLE [79fed072b] 2022-04-14 15:09:42 +0900
Branch: REL_10_STABLE [12d32b7bc] 2022-04-14 15:09:46 +0900
-->
     <para>
      Ensure that <filename>contrib/pageinspect</filename> functions cope
      with all-zero pages (Michael Paquier)
     </para>

     <para>
      This is a legitimate edge case, but the module was mostly unprepared
      for it.  Arrange to return nulls, or no rows, as appropriate; that
      seems more useful than raising an error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [291e517a4] 2022-03-27 17:53:40 +0900
Branch: REL_14_STABLE [27d384441] 2022-03-27 17:53:51 +0900
Branch: REL_13_STABLE [3d4d6dee0] 2022-03-27 17:53:55 +0900
Branch: REL_12_STABLE [5ca2aa2f2] 2022-03-27 17:53:59 +0900
Branch: REL_11_STABLE [1a2fdf86a] 2022-03-27 17:54:03 +0900
Branch: REL_10_STABLE [ab80b0fbb] 2022-03-27 17:54:08 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [076f4d953] 2022-03-16 11:19:39 +0900
Branch: REL_14_STABLE [b61e6214c] 2022-03-16 11:20:47 +0900
Branch: REL_13_STABLE [d3a9b83c3] 2022-03-16 11:20:51 +0900
Branch: REL_12_STABLE [af8a8eb54] 2022-03-16 11:20:54 +0900
Branch: REL_11_STABLE [2389ee8dd] 2022-03-16 11:20:57 +0900
Branch: REL_10_STABLE [c42b88932] 2022-03-16 11:21:00 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [4477dcb20] 2022-03-16 12:29:39 +0900
Branch: REL_14_STABLE [dc5b3bdae] 2022-03-16 12:29:47 +0900
Branch: REL_13_STABLE [028a3c6b1] 2022-03-16 12:29:55 +0900
Branch: REL_12_STABLE [5cb770210] 2022-03-16 12:29:59 +0900
Branch: REL_11_STABLE [09c97746d] 2022-03-16 12:30:02 +0900
Branch: REL_10_STABLE [07e343513] 2022-03-16 12:30:07 +0900
-->
     <para>
      In <filename>contrib/pageinspect</filename>, add defenses against
      incorrect page <quote>special space</quote> contents, tighten checks
      for correct page size, and add some missing checks that an index is
      of the expected type (Michael Paquier, Justin Pryzby, Julien
      Rouhaud)
     </para>

     <para>
      These changes make it less likely that the module will crash on bad
      data.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f3dd9fe1d] 2022-03-31 14:29:48 -0400
Branch: REL_14_STABLE [9f9489aa2] 2022-03-31 14:29:24 -0400
Branch: REL_13_STABLE [79df1d20c] 2022-03-31 14:29:24 -0400
Branch: REL_12_STABLE [989d3e4a2] 2022-03-31 14:29:24 -0400
Branch: REL_11_STABLE [b9eb0412f] 2022-03-31 14:29:24 -0400
Branch: REL_10_STABLE [728fc0f9a] 2022-03-31 14:29:24 -0400
-->
     <para>
      In <filename>contrib/postgres_fdw</filename>, verify
      that <literal>ORDER BY</literal> clauses are safe to ship before
      requesting a remotely-ordered query, and include
      a <literal>USING</literal> clause if necessary (Ronan Dunklau)
     </para>

     <para>
      This fix prevents situations where the remote server might sort in a
      different order than we intend.  While sometimes that would be only
      cosmetic, it could produce thoroughly wrong results if the remote
      data is used as input for a locally-performed merge join.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [e6a760020] 2021-09-27 10:53:20 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [807fee1a3] 2022-02-04 16:16:10 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [a56e7b660] 2022-03-16 10:30:55 +1300
Author: Thomas Munro <tmunro@postgresql.org>
Branch: REL_14_STABLE [d9f7ad54e] 2022-03-16 11:42:00 +1300
Branch: REL_13_STABLE [5610411ac] 2022-03-16 11:41:13 +1300
Branch: REL_12_STABLE [45a469eb2] 2022-03-16 11:40:43 +1300
Branch: REL_11_STABLE [986d24042] 2022-03-16 11:35:00 +1300
-->
     <para>
      Update <acronym>JIT</acronym> code to work with LLVM 14
      (Thomas Munro)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [46ab07ffd] 2022-03-03 18:13:24 -0500
Branch: REL_14_STABLE [b0bc196e5] 2022-03-03 18:13:24 -0500
Branch: REL_13_STABLE [1a027e6b7] 2022-03-03 18:13:24 -0500
Branch: REL_12_STABLE [f727b6ea8] 2022-03-03 18:13:24 -0500
Branch: REL_11_STABLE [f2087e26e] 2022-03-03 18:13:24 -0500
Branch: REL_10_STABLE [cfbe87bd6] 2022-03-03 18:13:24 -0500
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0fbdfaf79] 2022-03-03 19:03:17 -0500
Branch: REL_14_STABLE [5c9d17e94] 2022-03-03 19:03:35 -0500
Branch: REL_13_STABLE [97031f440] 2022-03-03 19:03:42 -0500
Branch: REL_12_STABLE [4b0696b36] 2022-03-03 19:03:46 -0500
Branch: REL_11_STABLE [566e1c04d] 2022-03-03 19:03:50 -0500
Branch: REL_10_STABLE [18c04d157] 2022-03-03 19:03:55 -0500
Author: Andres Freund <andres@anarazel.de>
Branch: master [3ac7d0241] 2022-03-23 13:05:59 -0700
Branch: REL_14_STABLE [81045e1e1] 2022-03-23 13:18:02 -0700
Branch: REL_13_STABLE [c0f99bb52] 2022-03-23 13:18:00 -0700
Branch: REL_12_STABLE [61a007fee] 2022-03-23 13:17:59 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: master [1c6bb380e] 2022-03-23 13:05:25 -0700
Branch: REL_14_STABLE [89a94c24a] 2022-03-23 13:13:18 -0700
Branch: REL_13_STABLE [8014c61eb] 2022-03-23 13:13:20 -0700
Branch: REL_12_STABLE [c5b60a68c] 2022-03-23 13:13:33 -0700
Branch: REL_11_STABLE [2121d5809] 2022-03-23 13:13:40 -0700
Branch: REL_10_STABLE [5f4615b9d] 2022-03-23 13:13:49 -0700
Author: Andres Freund <andres@anarazel.de>
Branch: master [e71c76fca] 2022-03-23 12:43:14 -0700
Branch: REL_14_STABLE [e52e9bd57] 2022-03-23 12:43:41 -0700
Branch: REL_13_STABLE [7c163aa93] 2022-03-23 12:43:40 -0700
Branch: REL_12_STABLE [6a767bc2e] 2022-03-23 12:43:38 -0700
Branch: REL_11_STABLE [a77dddb42] 2022-03-23 12:43:36 -0700
Branch: REL_10_STABLE [2a9193726] 2022-03-23 12:43:33 -0700
-->
     <para>
      Clean up assorted failures under <productname>clang</productname>'s
      <literal>-fsanitize=undefined</literal> checks (Tom Lane, Andres
      Freund, Zhihong Yu)
     </para>

     <para>
      Most of these changes are just for pro-forma compliance with the
      letter of the C and POSIX standards, and are unlikely to have any
      effect on production builds.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d5c2a91e5] 2022-02-08 19:25:56 -0500
Branch: REL_14_STABLE [e327291e4] 2022-02-08 19:26:09 -0500
Branch: REL_13_STABLE [5ea3b99de] 2022-02-08 19:26:17 -0500
Branch: REL_12_STABLE [eba0f095c] 2022-02-08 19:26:22 -0500
Branch: REL_11_STABLE [3a6e3a890] 2022-02-08 19:26:26 -0500
Branch: REL_10_STABLE [1a8b6f055] 2022-02-08 19:26:30 -0500
-->
     <para>
      Fix PL/Perl so it builds on C compilers that don't support statements
      nested within expressions (Tom Lane)
     </para>

     <para>
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [097786fbb] 2022-03-22 08:22:02 -0700
Branch: REL_14_STABLE [2d608c960] 2022-03-22 08:28:51 -0700
Branch: REL_13_STABLE [f183e23cc] 2022-03-22 08:28:52 -0700
Branch: REL_12_STABLE [4553b960f] 2022-03-22 08:28:53 -0700
Branch: REL_11_STABLE [cd1951ba0] 2022-03-22 08:28:54 -0700
Branch: REL_10_STABLE [083031aa9] 2022-03-22 08:28:55 -0700
-->
     <para>
      Fix possible build failure of <application>pg_dumpall</application>
      on Windows, when not using MSVC to build (Andres Freund)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [ea09a75e1] 2022-02-10 13:44:05 -0500
Branch: REL_14_STABLE [92f60f536] 2022-02-10 13:51:19 -0500
Branch: REL_13_STABLE [eec7c640f] 2022-02-10 13:51:40 -0500
Branch: REL_12_STABLE [64dd64807] 2022-02-10 13:51:49 -0500
Branch: REL_11_STABLE [e2d104e19] 2022-02-10 13:51:59 -0500
Branch: REL_10_STABLE [a5eef80c2] 2022-02-10 13:52:05 -0500
Branch: REL9_6_STABLE [622ab6a34] 2022-02-10 13:52:37 -0500
Branch: REL9_5_STABLE [3a5034b5e] 2022-02-10 13:53:56 -0500
Branch: REL9_4_STABLE [c76164ea0] 2022-02-10 13:56:55 -0500
-->
     <para>
      In Windows builds, use <application>gendef</application> instead
      of <application>pexports</application> to build DEF files (Andrew
      Dunstan)
     </para>

     <para>
      This adapts the build process to work on recent MSys tool chains.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [b787c554c] 2022-04-25 15:47:55 -0400
Branch: REL_14_STABLE [71f394667] 2022-04-25 15:49:35 -0400
Branch: REL_13_STABLE [d9cede2c3] 2022-04-25 15:50:01 -0400
Branch: REL_12_STABLE [01f2bc5af] 2022-04-25 15:50:07 -0400
Branch: REL_11_STABLE [b90ce0dd7] 2022-04-25 15:51:27 -0400
Branch: REL_10_STABLE [58887d58c] 2022-04-25 15:51:58 -0400
-->
     <para>
      Prevent extra expansion of shell wildcard patterns in programs built
      under MinGW (Andrew Dunstan)
     </para>

     <para>
      For some reason the C library provided by MinGW will expand shell
      wildcard characters in a program's command-line arguments by
      default.  This is confusing, not least because it doesn't happen
      under MSVC, so turn it off.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ab3479bf5] 2022-05-05 14:54:53 -0400
Branch: REL_14_STABLE [77ee14ed9] 2022-05-05 14:55:03 -0400
Branch: REL_13_STABLE [e9735d1af] 2022-05-05 14:55:10 -0400
Branch: REL_12_STABLE [2bb9f7501] 2022-05-05 14:55:17 -0400
Branch: REL_11_STABLE [da72ff09b] 2022-05-05 14:55:22 -0400
Branch: REL_10_STABLE [bc334ec9f] 2022-05-05 14:55:30 -0400
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2022a for DST law changes in Palestine, plus historical
      corrections for Chile and Ukraine.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-6">
  <title>Release 13.6</title>

  <formalpara>
  <title>Release date:</title>
  <para>2022-02-10</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.5.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.6</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you have applied <command>REINDEX CONCURRENTLY</command>
    to a TOAST table's index, or observe failures to access TOAST datums,
    see the first changelog entry below.
   </para>

   <para>
    Also, if you are upgrading from a version earlier than 13.5,
    see <xref linkend="release-13-5"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [f99870dd8] 2021-12-08 11:01:08 +0900
Branch: REL_14_STABLE [64ab21f0e] 2021-12-08 11:01:14 +0900
Branch: REL_13_STABLE [9acea52ea] 2021-12-08 11:01:19 +0900
Branch: REL_12_STABLE [5ed74d874] 2021-12-08 11:01:23 +0900
-->
     <para>
      Enforce standard locking protocol for TOAST table updates, to prevent
      problems with <command>REINDEX CONCURRENTLY</command> (Michael Paquier)
     </para>

     <para>
      If applied to a TOAST table or TOAST table's index, <command>REINDEX
      CONCURRENTLY</command> tended to produce a corrupted index.  This
      happened because sessions updating TOAST entries released
      their <literal>ROW EXCLUSIVE</literal> locks immediately, rather
      than holding them until transaction commit as all other updates do.
      The fix is to make TOAST updates hold the table lock according to the
      normal rule.  Any existing corrupted indexes can be repaired by
      reindexing again.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [6d554e3fc] 2022-01-23 03:16:31 +0100
Branch: REL_14_STABLE [a192243c7] 2022-01-23 03:18:02 +0100
Branch: REL_13_STABLE [267ccc38b] 2022-01-23 03:20:32 +0100
-->
     <para>
      Avoid null-pointer crash in <command>ALTER STATISTICS</command>
      when the statistics object is dropped concurrently (Tomas Vondra)
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [f9a74c149] 2022-01-25 21:10:03 +1300
Branch: REL_14_STABLE [357ff6615] 2022-01-25 21:14:27 +1300
Branch: REL_13_STABLE [f8807e774] 2022-01-25 21:15:00 +1300
Branch: REL_12_STABLE [2ccd8fb29] 2022-01-25 21:15:40 +1300
-->
     <para>
      Fix incorrect plan creation for parallel single-child Append nodes
      (David Rowley)
     </para>

     <para>
      In some cases the Append would be simplified away when it should not
      be, leading to wrong query results (duplicated rows).
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4ace45677] 2022-01-01 16:12:03 -0500
Branch: REL_14_STABLE [cabea571d] 2022-01-01 16:12:03 -0500
Branch: REL_13_STABLE [45ae42714] 2022-01-01 16:12:03 -0500
Branch: REL_12_STABLE [f789b7732] 2022-01-01 16:12:03 -0500
Branch: REL_11_STABLE [e3a4c7981] 2022-01-01 16:12:03 -0500
Branch: REL_10_STABLE [70a31a0e3] 2022-01-01 16:12:03 -0500
Branch: master [9a3ddeb51] 2022-01-03 15:42:27 -0500
Branch: REL_14_STABLE [d228af79d] 2022-01-03 15:42:27 -0500
Branch: REL_13_STABLE [20d08b2c6] 2022-01-03 15:42:27 -0500
Branch: REL_12_STABLE [9c4f38908] 2022-01-03 15:42:27 -0500
Branch: REL_11_STABLE [ec3674521] 2022-01-03 15:42:27 -0500
Branch: REL_10_STABLE [7d344f004] 2022-01-03 15:42:27 -0500
-->
     <para>
      Fix index-only scan plans for cases where not all index columns can
      be returned (Tom Lane)
     </para>

     <para>
      If an index has both returnable and non-returnable columns, and one
      of the non-returnable columns is an expression using a table column
      that appears in a returnable index column, then a query using that
      expression could result in an index-only scan plan that attempts to
      read the non-returnable column, instead of recomputing the
      expression from the returnable column as intended.  The
      non-returnable column would read as NULL, resulting in wrong query
      results.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9c356f4b2] 2021-12-16 15:36:02 -0500
Branch: REL_14_STABLE [f9a8bc9f2] 2021-12-16 15:36:02 -0500
Branch: REL_13_STABLE [da0d8a454] 2021-12-16 15:36:02 -0500
Branch: REL_12_STABLE [e1fd61c8c] 2021-12-16 15:36:02 -0500
Branch: REL_11_STABLE [c43d72b24] 2021-12-16 15:36:02 -0500
Branch: REL_10_STABLE [1acf34586] 2021-12-16 15:36:02 -0500
-->
     <para>
      Ensure that casting to an unspecified typmod generates a RelabelType
      node rather than a length-coercion function call (Tom Lane)
     </para>

     <para>
      While the coercion function should do the right thing (nothing),
      this translation is undesirably inefficient.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8e2e0f758] 2022-01-29 11:41:18 -0500
Branch: REL_14_STABLE [c025067f6] 2022-01-29 11:41:18 -0500
Branch: REL_13_STABLE [5ad70564f] 2022-01-29 11:41:12 -0500
-->
     <para>
      Fix checking of <type>anycompatible</type>-family data type matches
      (Tom Lane)
     </para>

     <para>
      In some cases the parser would think that a function or operator
      with <type>anycompatible</type>-family polymorphic parameters
      matches a set of arguments that it really shouldn't match.  In
      reported cases, that led to matching more than one operator to a
      call, leading to ambiguous-operator errors; but a failure later on
      is also possible.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [44bd3ed33] 2021-11-26 11:14:27 -0300
Branch: REL_14_STABLE [d24dac954] 2021-11-26 11:14:27 -0300
Branch: REL_13_STABLE [ef41c3fd6] 2021-11-26 11:14:27 -0300
Branch: REL_12_STABLE [9c6ab1ef3] 2021-11-26 11:14:27 -0300
Branch: REL_11_STABLE [2c3fddcbb] 2021-11-26 11:14:27 -0300
Branch: REL_10_STABLE [72cf39d51] 2021-11-26 11:14:27 -0300
-->
     <para>
      Fix WAL replay failure when database consistency is reached exactly
      at a WAL page boundary (&Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [f192e1bdf] 2022-01-27 20:13:55 +0100
Branch: REL_14_STABLE [fb2f8e534] 2022-01-27 20:15:37 +0100
Branch: REL_13_STABLE [e90f258ac] 2022-01-27 20:16:39 +0100
Branch: REL_12_STABLE [4b8af2bf8] 2022-01-27 20:17:36 +0100
Branch: REL_11_STABLE [5cb88648e] 2022-01-27 20:18:22 +0100
Branch: REL_10_STABLE [4ef38fbe8] 2022-01-27 20:19:39 +0100
-->
     <para>
      Fix startup of a physical replica to tolerate transaction ID
      wraparound (Abhijit Menon-Sen, Tomas Vondra)
     </para>

     <para>
      If a replica server is started while the set of active transactions
      on the primary crosses a wraparound boundary (so that there are some
      newer transactions with smaller XIDs than older ones), the replica
      would fail with <quote>out-of-order XID insertion in
      KnownAssignedXids</quote>.  The replica would retry, but could never
      get past that error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [5e97905a2] 2021-12-09 08:36:59 +0530
Branch: REL_14_STABLE [614b77d65] 2021-12-09 08:49:50 +0530
Branch: REL_13_STABLE [3f06c00cf] 2021-12-09 09:00:35 +0530
-->
     <para>
      In logical replication, avoid double transmission of a child table's
      data (Hou Zhijie)
     </para>

     <para>
      If a publication includes both child and parent tables, and has
      the <literal>publish_via_partition_root</literal> option set,
      subscribers uselessly initiated synchronization on both child and
      parent tables.  Ensure that only the parent table is synchronized in
      such cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [6aa518614] 2022-01-24 15:33:38 -0500
Branch: REL_14_STABLE [1efcc5946] 2022-01-24 15:33:34 -0500
Branch: REL_13_STABLE [d67354d87] 2022-01-24 15:33:34 -0500
Branch: REL_12_STABLE [689f75d6e] 2022-01-24 15:33:34 -0500
Branch: REL_11_STABLE [4ec54498c] 2022-01-24 15:33:34 -0500
Branch: REL_10_STABLE [9af6d4b5a] 2022-01-24 15:33:34 -0500
Branch: master [3c06ec6d1] 2022-01-24 12:09:46 -0500
Branch: REL_14_STABLE [ef9706bbc] 2022-01-24 12:09:46 -0500
Branch: REL_13_STABLE [c94c6612d] 2022-01-24 12:09:46 -0500
Branch: REL_12_STABLE [a8ce5c8d7] 2022-01-24 12:09:46 -0500
Branch: REL_11_STABLE [449a69623] 2022-01-24 12:09:46 -0500
Branch: REL_10_STABLE [daf658982] 2022-01-24 12:09:46 -0500
-->
     <para>
      Remove lexical limitations for SQL commands issued on a logical
      replication connection (Tom Lane)
     </para>

     <para>
      The walsender process would fail for a SQL command containing an
      unquoted semicolon, or with dollar-quoted literals containing odd
      numbers of single or double quote marks, or when the SQL command
      starts with a comment.  Moreover, faulty error recovery could lead
      to unexpected errors in later commands too.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [237d1f317] 2022-01-21 14:54:04 +0900
Branch: REL_14_STABLE [84db5169d] 2022-01-21 14:54:47 +0900
Branch: REL_13_STABLE [b5f634116] 2022-01-21 14:54:51 +0900
Branch: REL_12_STABLE [1c0452c48] 2022-01-21 14:54:55 +0900
Branch: REL_11_STABLE [0ffe2975c] 2022-01-21 14:54:59 +0900
Branch: REL_10_STABLE [919be95c6] 2022-01-21 14:55:04 +0900
-->
     <para>
      Fix possible loss of the commit timestamp for the last
      subtransaction of a transaction (Alex Kingsborough, Kyotaro Horiguchi)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [1fabec7d7] 2022-01-21 11:22:55 -0800
Branch: REL_14_STABLE [2b7dbe4bd] 2022-01-21 11:24:12 -0800
Branch: REL_13_STABLE [fd48e5f5d] 2022-01-21 11:24:12 -0800
Branch: REL_12_STABLE [1c6d055ba] 2022-01-21 11:24:12 -0800
Branch: REL_11_STABLE [2c15b29f7] 2022-01-21 11:24:12 -0800
Branch: REL_10_STABLE [f862cc09f] 2022-01-21 11:24:12 -0800
-->
     <para>
      Be sure to <function>fsync</function>
      the <filename>pg_logical/mappings</filename> subdirectory during
      checkpoints (Nathan Bossart)
     </para>

     <para>
      On some filesystems this oversight could lead to losing logical
      rewrite status files after a system crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [20b9fa308] 2022-01-15 19:06:48 +0100
Branch: REL_14_STABLE [ea212bd95] 2022-01-15 19:05:22 +0100
Branch: REL_13_STABLE [d6817032d] 2022-01-15 19:14:00 +0100
Branch: REL_12_STABLE [9d1bcf5dc] 2022-01-15 19:02:58 +0100
Branch: REL_11_STABLE [491182e52] 2022-01-15 18:32:20 +0100
Branch: REL_10_STABLE [9211c2e38] 2022-01-15 18:30:45 +0100
-->
     <para>
      Build extended statistics for partitioned tables (Justin Pryzby)
     </para>

     <para>
      A previous bug fix disabled building of extended statistics for
      old-style inheritance trees, but it also prevented building them for
      partitioned tables, which was an unnecessary restriction.
      This change allows <command>ANALYZE</command> to compute values for
      statistics objects for partitioned tables.  (But note that
      autovacuum does not process partitioned tables as such, so you must
      periodically issue manual <command>ANALYZE</command> on the
      partitioned table if you want to maintain such statistics.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [36c4bc6e7] 2022-01-15 02:20:54 +0100
Branch: REL_14_STABLE [2cc007fd0] 2022-01-15 02:26:26 +0100
Branch: REL_13_STABLE [acfde7c58] 2022-01-15 02:30:06 +0100
Branch: REL_12_STABLE [76569ad6f] 2022-01-15 03:14:55 +0100
Branch: REL_11_STABLE [b3cac25f4] 2022-01-15 02:40:40 +0100
Branch: REL_10_STABLE [ff0e7c7e8] 2022-01-15 03:05:06 +0100
-->
     <para>
      Ignore extended statistics for inheritance trees (Justin Pryzby)
     </para>

     <para>
      Currently, extended statistics values are only computed locally for
      each table, not for entire inheritance trees.  However the values
      were mistakenly consulted when planning queries across inheritance
      trees, possibly resulting in worse-than-default estimates.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7ead9925f] 2022-01-06 16:46:46 -0500
Branch: REL_14_STABLE [f285d9583] 2022-01-06 16:46:46 -0500
Branch: REL_13_STABLE [86d4bbb56] 2022-01-06 16:46:46 -0500
Branch: REL_12_STABLE [ccc7c3ad8] 2022-01-06 16:46:46 -0500
Branch: REL_11_STABLE [2ce113a4f] 2022-01-06 16:46:46 -0500
Branch: REL_10_STABLE [e5b044c84] 2022-01-06 16:46:46 -0500
-->
     <para>
      Disallow altering data type of a partitioned table's columns when
      the partitioned table's row type is used as a composite type
      elsewhere (Tom Lane)
     </para>

     <para>
      This restriction has long existed for regular tables, but through an
      oversight it was not checked for partitioned tables.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [f0d43947a] 2021-11-25 15:04:56 +0900
Branch: REL_14_STABLE [e415916e2] 2021-11-25 15:05:24 +0900
Branch: REL_13_STABLE [37827de43] 2021-11-25 15:05:28 +0900
Branch: REL_12_STABLE [216156fec] 2021-11-25 15:05:31 +0900
Branch: REL_11_STABLE [dffe80e55] 2021-11-25 15:05:34 +0900
Branch: REL_10_STABLE [817c469c2] 2021-11-25 15:05:37 +0900
-->
     <para>
      Disallow <literal>ALTER TABLE ... DROP NOT NULL</literal> for a
      column that is part of a replica identity index (Haiying Tang, Hou
      Zhijie)
     </para>

     <para>
      The same prohibition already existed for primary key indexes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d8fbbb925] 2022-01-22 13:32:40 -0500
Branch: REL_14_STABLE [3839e29c5] 2022-01-22 13:32:40 -0500
Branch: REL_13_STABLE [31b7b4d26] 2022-01-22 13:32:40 -0500
Branch: REL_12_STABLE [e2d53c876] 2022-01-22 13:32:40 -0500
Branch: REL_11_STABLE [26c841ed1] 2022-01-22 13:32:40 -0500
-->
     <para>
      Correctly update cached table state during <command>ALTER TABLE ADD
      PRIMARY KEY USING INDEX</command> (Hou Zhijie)
     </para>

     <para>
      Concurrent sessions failed to update their opinion of whether the
      table has a primary key, possibly causing incorrect logical
      replication behavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [354a1f8d2] 2021-11-16 08:10:13 +0530
Branch: REL_14_STABLE [232fd72a5] 2021-11-16 08:34:24 +0530
Branch: REL_13_STABLE [63c3eeddc] 2021-11-16 08:46:12 +0530
Branch: REL_12_STABLE [9816e2d31] 2021-11-16 09:05:51 +0530
Branch: REL_11_STABLE [40fb634b1] 2021-11-16 09:25:04 +0530
Branch: REL_10_STABLE [2c0443c59] 2021-11-16 09:44:00 +0530
-->
     <para>
      Correctly update cached table state when switching <literal>REPLICA
      IDENTITY</literal> index (Tang Haiying, Hou Zhijie)
     </para>

     <para>
      Concurrent sessions failed to update their opinion of which index is
      the replica identity one, possibly causing incorrect logical
      replication behavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [0f0cfb494] 2021-11-19 09:04:40 +0530
Branch: REL_14_STABLE [ead49ebc0] 2021-11-19 09:14:09 +0530
Branch: REL_13_STABLE [33b6dd83e] 2021-11-19 09:24:00 +0530
-->
     <para>
      Allow parallel vacuuming and concurrent index building to be ignored
      while computing oldest xmin (Masahiko Sawada)
     </para>

     <para>
      Non-parallelized instances of these operations were already ignored,
      but the logic did not work for parallelized cases.  Holding back the
      xmin horizon has undesirable effects such as delaying vacuum
      cleanup.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [babe545ca] 2021-12-01 13:44:46 -0500
Branch: REL_14_STABLE [8f4b0200e] 2021-12-01 13:44:47 -0500
Branch: REL_13_STABLE [7413caabe] 2021-12-01 13:44:47 -0500
Branch: REL_12_STABLE [5cf08b4db] 2021-12-01 13:44:47 -0500
Branch: REL_11_STABLE [82d354411] 2021-12-01 13:44:47 -0500
Branch: REL_10_STABLE [fec187dc3] 2021-12-01 13:44:47 -0500
-->
     <para>
      Avoid leaking memory during <command>REASSIGN OWNED BY</command>
      operations that reassign ownership of many objects (Justin Pryzby)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [6ce16088b] 2022-01-05 10:27:07 +0900
Branch: REL_14_STABLE [5ddfebded] 2022-01-05 10:27:47 +0900
Branch: REL_13_STABLE [3f8062bcf] 2022-01-05 10:27:53 +0900
-->
     <para>
      Improve performance of walsenders sending logical changes by
      avoiding unnecessary cache accesses (Hou Zhijie)
     </para>
    </listitem>

    <listitem>
<!--
Author: Magnus Hagander <magnus@hagander.net>
Branch: master [2dbb7b9b2] 2022-01-26 09:58:59 +0100
Branch: REL_14_STABLE [4afae689e] 2022-01-26 09:59:14 +0100
Branch: REL_13_STABLE [81596645c] 2022-01-26 09:59:19 +0100
Branch: REL_12_STABLE [aa58f5c53] 2022-01-26 09:59:23 +0100
-->
     <para>
      Fix display of <literal>cert</literal> authentication method's
      options in <structname>pg_hba_file_rules</structname> view (Magnus
      Hagander)
     </para>

     <para>
      The <literal>cert</literal> authentication method implies
      <literal>clientcert=verify-full</literal>, but the
      <structname>pg_hba_file_rules</structname> view incorrectly reported
      <literal>clientcert=verify-ca</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [43c217512] 2022-01-13 17:49:46 -0500
Branch: REL_14_STABLE [4aee39ddb] 2022-01-13 17:49:26 -0500
Branch: REL_13_STABLE [ca14c4184] 2022-01-13 17:49:26 -0500
Branch: REL_12_STABLE [45a3cefad] 2022-01-13 17:49:26 -0500
Branch: REL_11_STABLE [3a1bfe256] 2022-01-13 17:49:26 -0500
Branch: REL_10_STABLE [3433a1fc7] 2022-01-13 17:49:26 -0500
-->
     <para>
      Fix display of whole-row variables appearing
      in <literal>INSERT ... VALUES</literal> rules (Tom Lane)
     </para>

     <para>
      A whole-row variable would be printed as <quote>var.*</quote>,
      but that allows it to be expanded to individual columns when
      the rule is reloaded, resulting in different semantics.
      Attach an explicit cast to prevent that, as we do elsewhere.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [098c13455] 2021-11-11 15:00:59 +0900
Branch: REL_14_STABLE [b609db715] 2021-11-11 15:01:45 +0900
Branch: REL_13_STABLE [13c8adf90] 2021-11-11 15:01:54 +0900
-->
     <para>
      Fix one-byte buffer overrun when applying Unicode string
      normalization to an empty string (Michael Paquier)
     </para>

     <para>
      The practical impact of this is limited thanks to alignment
      considerations; but in debug builds, a warning was raised.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [f66885bec] 2022-01-04 13:01:05 -0300
Branch: REL_14_STABLE [f185f35a8] 2022-01-04 13:01:05 -0300
Branch: REL_13_STABLE [29f9fb8fe] 2022-01-04 13:01:05 -0300
Branch: REL_12_STABLE [6b681cd05] 2022-01-04 13:01:05 -0300
Branch: REL_11_STABLE [28cd57416] 2022-01-04 13:01:05 -0300
Branch: REL_10_STABLE [026a93727] 2022-01-04 13:01:05 -0300
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [67a8cb5cb] 2022-01-04 13:21:23 -0300
Branch: REL_14_STABLE [f9db153c2] 2022-01-04 13:21:23 -0300
Branch: REL_13_STABLE [33fdd9f85] 2022-01-04 13:21:23 -0300
Branch: REL_12_STABLE [397b43948] 2022-01-04 13:21:23 -0300
Branch: REL_11_STABLE [b63851a45] 2022-01-04 13:21:23 -0300
Branch: REL_10_STABLE [4a8282425] 2022-01-04 13:21:23 -0300
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [2e577c944] 2021-12-22 15:38:00 +0900
Branch: REL_14_STABLE [8a22a40b2] 2021-12-22 15:38:05 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [ece8c7619] 2021-12-14 10:58:15 +0900
Branch: REL_14_STABLE [4be3e005e] 2021-12-14 10:58:25 +0900
Branch: REL_13_STABLE [3f710fc2b] 2021-12-14 10:58:29 +0900
Branch: REL_12_STABLE [65af1e842] 2021-12-14 10:58:33 +0900
Branch: REL_11_STABLE [8abb6c27e] 2021-12-14 10:58:37 +0900
-->
     <para>
      Fix or remove some incorrect assertions (Simon Riggs, Michael
      Paquier, Alexander Lakhin)
     </para>

     <para>
      These errors should affect only debug builds, not production.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1f655fdc3] 2022-01-21 15:36:27 -0500
Branch: REL_14_STABLE [f4ebf0dbe] 2022-01-21 15:36:28 -0500
Branch: REL_13_STABLE [64ebb43df] 2022-01-21 15:36:28 -0500
Branch: REL_12_STABLE [5521d8139] 2022-01-21 15:36:29 -0500
Branch: REL_11_STABLE [37f5dc8b8] 2022-01-21 15:36:29 -0500
Branch: REL_10_STABLE [0c7c94f90] 2022-01-21 15:36:30 -0500
-->
     <para>
      Fix race condition that could lead to failure to localize error
      messages that are reported early in multi-threaded use
      of <application>libpq</application>
      or <application>ecpglib</application> (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f3f467b8f] 2022-01-17 12:52:44 -0500
Branch: REL_14_STABLE [050949877] 2022-01-17 12:52:44 -0500
Branch: REL_13_STABLE [f27af7b88] 2022-01-17 12:52:44 -0500
Branch: REL_12_STABLE [38f099ef9] 2022-01-17 12:52:44 -0500
Branch: REL_11_STABLE [8b107467c] 2022-01-17 12:52:44 -0500
Branch: REL_10_STABLE [9d66c43eb] 2022-01-17 12:52:45 -0500
-->
     <para>
      Avoid calling <function>strerror</function>
      from <application>libpq</application>'s <function>PQcancel</function>
      function (Tom Lane)
     </para>

     <para>
      <function>PQcancel</function> is supposed to be safe to call from a
      signal handler, but <function>strerror</function> is not safe.  The
      faulty usage only occurred in the unlikely event of failure to
      send the cancel message to the server, perhaps explaining the lack
      of reports.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d6eb5a0c2] 2021-11-12 14:55:32 -0500
Branch: REL_14_STABLE [99389cb66] 2021-11-12 14:55:32 -0500
Branch: REL_13_STABLE [843925fad] 2021-11-12 14:55:32 -0500
Branch: REL_12_STABLE [523adcc12] 2021-11-12 14:55:32 -0500
Branch: REL_11_STABLE [b062ca508] 2021-11-12 14:55:32 -0500
Branch: REL_10_STABLE [3bc46e4e9] 2021-11-12 14:55:32 -0500
-->
     <para>
      Make <application>psql</application>'s <command>\password</command>
      command default to setting the password
      for <literal>CURRENT_USER</literal>, not the connection's original
      user name (Tom Lane)
     </para>

     <para>
      This agrees with the documented behavior, and avoids probable
      permissions failure if <command>SET ROLE</command> or <command>SET
      SESSION AUTHORIZATION</command> has been done since the session began.
      To prevent confusion, the role name to be acted on is now
      included in the password prompt.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9007d4ea7] 2022-01-17 21:19:02 -0500
Branch: REL_14_STABLE [3886785b4] 2022-01-17 21:18:49 -0500
Branch: REL_13_STABLE [90e0f9fd8] 2022-01-17 21:18:49 -0500
-->
     <para>
      Fix <application>psql</application> <literal>\d</literal> command's
      query for identifying parent triggers (Justin Pryzby)
     </para>

     <para>
      The previous coding failed with <quote>more than one row returned by
      a subquery used as an expression</quote> if a partition had triggers
      and there were unrelated statement-level triggers of the same name
      on some parent partitioned table.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [fe7551744] 2022-01-16 14:59:20 -0500
Branch: REL_14_STABLE [d91d4338e] 2022-01-16 14:59:20 -0500
Branch: REL_13_STABLE [90a847e6d] 2022-01-16 14:59:20 -0500
-->
     <para>
      Fix <application>psql</application>'s tab-completion of label values
      for enum types (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2131c049d] 2022-01-17 13:30:04 -0500
Branch: REL_14_STABLE [4e8726566] 2022-01-17 13:30:04 -0500
Branch: REL_13_STABLE [d18ec312f] 2022-01-17 13:30:04 -0500
Branch: REL_12_STABLE [6d1a854c1] 2022-01-17 13:30:04 -0500
Branch: REL_11_STABLE [92e6c1c9b] 2022-01-17 13:30:04 -0500
Branch: REL_10_STABLE [62bfa554b] 2022-01-17 13:30:04 -0500
-->
     <para>
      In <application>psql</application> and some other client programs,
      avoid trying to invoke <function>gettext()</function> from a
      control-C signal handler (Tom Lane)
     </para>

     <para>
      While no reported failures have been traced to this mistake, it seems
      highly unlikely to be a safe thing to do.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [282b6d00a] 2021-11-21 14:13:35 -0500
Branch: REL_14_STABLE [3bd7556bb] 2021-11-21 14:13:35 -0500
Branch: REL_13_STABLE [33edf4a3c] 2021-11-21 14:13:35 -0500
Branch: REL_12_STABLE [93295932d] 2021-11-21 14:13:35 -0500
Branch: REL_11_STABLE [c2242d364] 2021-11-21 14:13:35 -0500
Branch: REL_10_STABLE [3ce5d0884] 2021-11-21 14:13:35 -0500
-->
     <para>
      Allow canceling the initial password prompt
      in <application>pg_receivewal</application>
      and <application>pg_recvlogical</application> (Tom Lane, Nathan
      Bossart)
     </para>

     <para>
      Previously it was impossible to terminate these programs via control-C
      while they were prompting for a password.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b55f2b692] 2021-11-22 17:16:29 -0500
Branch: REL_14_STABLE [0fdf67476] 2021-11-22 17:16:29 -0500
Branch: REL_13_STABLE [d4f6a36d8] 2021-11-22 17:16:29 -0500
Branch: REL_12_STABLE [69949ea68] 2021-11-22 17:16:29 -0500
Branch: REL_11_STABLE [54619a25d] 2021-11-22 17:16:29 -0500
Branch: REL_10_STABLE [2b36973d9] 2021-11-22 17:16:29 -0500
-->
     <para>
      Fix <application>pg_dump</application>'s dump ordering for
      user-defined casts (Tom Lane)
     </para>

     <para>
      In rare cases, the output script might refer to a user-defined cast
      before it had been created.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0b126c6a4] 2021-11-22 15:25:48 -0500
Branch: REL_14_STABLE [aedc4600d] 2021-11-22 15:25:48 -0500
Branch: REL_13_STABLE [6fc8b145e] 2021-11-22 15:25:48 -0500
Branch: REL_12_STABLE [1e7f588ad] 2021-11-22 15:25:48 -0500
Branch: master [db3a660c6] 2021-11-22 15:57:31 -0500
Branch: REL_14_STABLE [72842a575] 2021-11-22 15:57:43 -0500
Branch: REL_13_STABLE [b542e4596] 2021-11-22 15:57:52 -0500
Branch: REL_12_STABLE [72582531b] 2021-11-22 15:57:59 -0500
Branch: REL_11_STABLE [22d2b6611] 2021-11-22 15:58:05 -0500
Branch: REL_10_STABLE [b599b8f39] 2021-11-22 15:58:12 -0500
-->
     <para>
      Fix <application>pg_dump</application>'s <option>--inserts</option>
      and  <option>--column-inserts</option> modes to handle tables
      containing both generated columns and dropped columns (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [248c3a937] 2021-11-17 14:16:34 -0500
Branch: REL_14_STABLE [53c4a580e] 2021-11-17 14:16:34 -0500
Branch: REL_13_STABLE [c8b5221b5] 2021-11-17 14:16:34 -0500
Branch: REL_12_STABLE [8378dad4c] 2021-11-17 14:16:34 -0500
Branch: REL_11_STABLE [a414eb850] 2021-11-17 14:16:34 -0500
Branch: REL_10_STABLE [13799bb93] 2021-11-17 14:16:34 -0500
Branch: master [3cac2c8ca] 2021-11-17 13:08:25 -0500
Branch: REL_14_STABLE [6b413b41b] 2021-11-17 13:08:25 -0500
Branch: REL_13_STABLE [bbda88c33] 2021-11-17 13:08:25 -0500
Branch: REL_12_STABLE [12bf11889] 2021-11-17 13:08:25 -0500
-->
     <para>
      Fix possible mis-reporting of errors
      in <application>pg_dump</application>
      and <application>pg_basebackup</application> (Tom Lane)
     </para>

     <para>
      The previous code failed to check for errors from some kernel calls,
      and could report the wrong errno values in other cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [54b1cb7eb] 2022-01-08 14:54:39 -0500
Branch: REL_14_STABLE [043c1e1a7] 2022-01-08 14:54:39 -0500
Branch: REL_13_STABLE [823d4c7e2] 2022-01-08 14:54:39 -0500
Branch: REL_12_STABLE [3a69d45af] 2022-01-08 14:54:39 -0500
Branch: REL_11_STABLE [38cbdd22d] 2022-01-08 14:54:39 -0500
Branch: REL_10_STABLE [b21986908] 2022-01-08 14:54:39 -0500
-->
     <para>
      Fix results of index-only scans
      on <filename>contrib/btree_gist</filename> indexes
      on <type>char(<replaceable>N</replaceable>)</type> columns (Tom Lane)
     </para>

     <para>
      Index-only scans returned column values with trailing spaces
      removed, which is not the expected behavior.  That happened because
      that's how the data was stored in the index.  This fix changes the
      code to store <type>char(<replaceable>N</replaceable>)</type> values
      with the expected amount of space padding.
      The behavior of such an index will not change immediately unless
      you <command>REINDEX</command> it; otherwise space-stripped values
      will be gradually replaced over time during updates.  Queries that
      do not use index-only scan plans will be unaffected in any case.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [bd233bdd8] 2022-01-25 18:52:44 -0500
Branch: REL_14_STABLE [803f0b173] 2022-02-01 19:03:41 -0500
Branch: REL_13_STABLE [4d7d196ff] 2022-02-01 19:03:41 -0500
Branch: REL_12_STABLE [aa2215d6b] 2022-02-01 19:03:41 -0500
Branch: REL_11_STABLE [e41176bd6] 2022-02-01 19:03:41 -0500
Branch: REL_10_STABLE [a72c43012] 2022-02-01 19:03:41 -0500
-->
     <para>
      Change <application>configure</application> to use
      Python's <application>sysconfig</application> module, rather than
      the deprecated <application>distutils</application> module, to
      determine how to build PL/Python (Peter Eisentraut, Tom Lane, Andres
      Freund)
     </para>

     <para>
      With Python 3.10, this
      avoids <application>configure</application>-time warnings
      about <application>distutils</application> being deprecated and
      scheduled for removal in Python 3.12.  Presumably, once 3.12 is
      out, <literal>configure --with-python</literal> would fail
      altogether.  This future-proofing does come at a
      cost: <application>sysconfig</application> did not exist before
      Python 2.7, nor before 3.2 in the Python 3 branch, so it is no
      longer possible to build PL/Python against long-dead Python
      versions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [c89f40974] 2022-01-30 16:42:14 -0800
Branch: REL_14_STABLE [8484e3812] 2022-01-30 16:42:42 -0800
Branch: REL_13_STABLE [0dc0fe7b6] 2022-01-30 16:42:45 -0800
Branch: REL_12_STABLE [f173738d5] 2022-01-30 16:42:47 -0800
Branch: REL_11_STABLE [ad95a639a] 2022-01-30 16:42:49 -0800
Branch: REL_10_STABLE [2557a03f8] 2022-01-30 16:43:07 -0800
-->
     <para>
      Fix PL/Perl compile failure on Windows with Perl 5.28 and later
      (Victor Wagner)
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [99e4d24a9] 2021-11-25 14:19:22 +0100
Branch: REL_14_STABLE [1cc13b83e] 2021-11-25 14:30:12 +0100
Branch: REL_13_STABLE [04875ae92] 2021-11-25 14:30:46 +0100
Branch: REL_12_STABLE [0d335cbd5] 2021-11-25 14:31:01 +0100
Branch: REL_11_STABLE [a83b1bab0] 2021-11-25 14:32:26 +0100
Branch: REL_10_STABLE [4339e10f0] 2021-11-25 14:32:43 +0100
-->
     <para>
      Fix PL/Python compile failure with Python 3.11 and later (Peter
      Eisentraut)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [b2265d305] 2021-11-24 13:03:23 +0900
Branch: REL_14_STABLE [0e681fa45] 2021-11-24 13:03:55 +0900
Branch: REL_13_STABLE [baef657d3] 2021-11-24 13:03:59 +0900
Branch: REL_12_STABLE [420d5e40b] 2021-11-24 13:04:03 +0900
Branch: REL_11_STABLE [1061e41ff] 2021-11-24 13:04:07 +0900
Branch: REL_10_STABLE [82881a9b9] 2021-11-24 13:04:12 +0900
-->
     <para>
      Add support for building with Visual Studio 2022 (Hans Buschmann)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [c3879a7b4] 2022-01-07 16:07:45 -0500
Branch: REL_14_STABLE [a7772e874] 2022-01-07 16:14:04 -0500
Branch: REL_13_STABLE [f3ded9c46] 2022-01-07 16:14:16 -0500
Branch: REL_12_STABLE [a4cde9153] 2022-01-07 16:14:23 -0500
Branch: REL_11_STABLE [c7fa0f55d] 2022-01-07 16:14:32 -0500
Branch: REL_10_STABLE [d897361c7] 2022-01-07 16:14:40 -0500
Branch: master [f80900be0] 2022-01-20 10:13:18 -0500
Branch: REL_14_STABLE [156a846d9] 2022-01-20 10:20:40 -0500
Branch: REL_13_STABLE [31680730e] 2022-01-20 10:20:51 -0500
Branch: REL_12_STABLE [22d8c2570] 2022-01-20 10:21:02 -0500
Branch: REL_11_STABLE [0a79feeca] 2022-01-20 10:21:12 -0500
Branch: REL_10_STABLE [a5bd14d93] 2022-01-20 10:21:28 -0500
-->
     <para>
      Allow the <filename>.bat</filename> wrapper scripts in our MSVC
      build system to be called without first changing into their
      directory (Anton Voloshin, Andrew Dunstan)
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-5">
  <title>Release 13.5</title>

  <formalpara>
  <title>Release date:</title>
  <para>2021-11-11</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.4.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.5</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, note that installations using physical replication should
    update standby servers before the primary server, as explained in
    the third 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>

   <para>
    Also, if you are upgrading from a version earlier than 13.2,
    see <xref linkend="release-13-2"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [28e241255] 2021-11-08 11:01:43 -0500
Branch: REL_14_STABLE [9d5a76b8d] 2021-11-08 11:01:43 -0500
Branch: REL_13_STABLE [e92ed93e8] 2021-11-08 11:01:43 -0500
Branch: REL_12_STABLE [d1bd26740] 2021-11-08 11:01:43 -0500
Branch: REL_11_STABLE [9394fb828] 2021-11-08 11:01:43 -0500
Branch: REL_10_STABLE [9ae0f1112] 2021-11-08 11:01:43 -0500
Branch: REL9_6_STABLE [046c2c846] 2021-11-08 11:01:43 -0500
-->
     <para>
      Make the server reject extraneous data after an SSL or GSS
      encryption handshake (Tom Lane)
     </para>

     <para>
      A man-in-the-middle with the ability to inject data into the TCP
      connection could stuff some cleartext data into the start of a
      supposedly encryption-protected database session.
      This could be abused to send faked SQL commands to the server,
      although that would only work if the server did not demand any
      authentication data.  (However, a server relying on SSL certificate
      authentication might well not do so.)
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Jacob Champion for reporting this problem.
      (CVE-2021-23214)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [160c02588] 2021-11-08 11:14:56 -0500
Branch: REL_14_STABLE [30547d791] 2021-11-08 11:14:56 -0500
Branch: REL_13_STABLE [844b31692] 2021-11-08 11:14:56 -0500
Branch: REL_12_STABLE [36bb95ef2] 2021-11-08 11:14:56 -0500
Branch: REL_11_STABLE [a021a1d2a] 2021-11-08 11:14:56 -0500
Branch: REL_10_STABLE [e65d9c8cd] 2021-11-08 11:14:56 -0500
Branch: REL9_6_STABLE [d83cdfdca] 2021-11-08 11:14:57 -0500
-->
     <para>
      Make <application>libpq</application> reject extraneous data after
      an SSL or GSS encryption handshake (Tom Lane)
     </para>

     <para>
      A man-in-the-middle with the ability to inject data into the TCP
      connection could stuff some cleartext data into the start of a
      supposedly encryption-protected database session.
      This could probably be abused to inject faked responses to the
      client's first few queries, although other details of libpq's
      behavior make that harder than it sounds.  A different line of
      attack is to exfiltrate the client's password, or other sensitive
      data that might be sent early in the session.  That has been shown
      to be possible with a server vulnerable to CVE-2021-23214.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Jacob Champion for reporting this problem.
      (CVE-2021-23222)
     </para>
    </listitem>

    <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: 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: 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: 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 =
      val</literal> failed if the array's 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, since it cannot stop until it finds a row
      that is not a tie.  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 then the collation could not be
      referenced 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 accepted 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 match in places where 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>
      Incorrect back-tracking logic could result in exponential time spent
      looking for a match.  Fortunately the problem is masked in most
      cases by other optimizations.
     </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 [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: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [05e6e78c1] 2021-11-06 19:13:58 +0300
Branch: REL_14_STABLE [b0f6bd48f] 2021-11-06 19:13:53 +0300
Branch: REL_13_STABLE [e1fee28a0] 2021-11-06 18:34:19 +0300
Branch: REL_12_STABLE [8f779a1a3] 2021-11-06 18:34:21 +0300
Branch: REL_11_STABLE [691c0df73] 2021-11-06 18:34:23 +0300
Branch: REL_10_STABLE [774d00573] 2021-11-06 18:34:26 +0300
Branch: REL9_6_STABLE [7381b79ad] 2021-11-06 18:34:31 +0300
-->
     <para>
      Prevent wraparound of overflowed-subtransaction tracking on standby
      servers (Kyotaro Horiguchi, Alexander Korotkov)
     </para>

     <para>
      This oversight could cause significant performance degradation
      (manifesting as excessive SubtransSLRU traffic) on standby servers.
     </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 that 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 [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 <literal>REPEATABLE
      READ</literal>.
     </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>
      Ensure that walreceiver processes create all required archive
      notification files before exiting (Fujii Masao)
     </para>

     <para>
      If a walreceiver exited exactly at a WAL segment boundary, it failed
      to make a notification file for the last-received segment, thus
      delaying archiving of that 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>
      Fix computation of the 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 that the 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 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: 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 [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 again 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 due to fewer network round-trips.
     </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: 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: 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 [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-13-4">
  <title>Release 13.4</title>

  <formalpara>
  <title>Release date:</title>
  <para>2021-08-12</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.3.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.4</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you are upgrading from a version earlier than 13.2,
    see <xref linkend="release-13-2"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [6ee41a301] 2021-05-31 12:03:00 -0400
Branch: REL_13_STABLE [fe6f63286] 2021-05-31 12:03:00 -0400
Branch: REL_12_STABLE [6f9e7f21f] 2021-05-31 12:03:00 -0400
Branch: REL_11_STABLE [fe194f731] 2021-05-31 12:03:00 -0400
-->
     <para>
      Fix mis-planning of repeated application of a projection step
      (Tom Lane)
     </para>

     <para>
      The planner could create an incorrect plan in cases where two
      ProjectionPaths were stacked on top of each other.  The only known
      way to trigger that situation involves parallel sort operations, but
      there may be other instances.  The result would be crashes or
      incorrect query results.
      Disclosure of server memory contents is also possible.
      (CVE-2021-3677)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_14_BR [01e6f1a84] 2021-05-25 10:10:09 +0900
Branch: REL_13_STABLE [a23c0b00f] 2021-05-25 10:11:13 +0900
Branch: REL_12_STABLE [3f8072be8] 2021-05-25 10:11:17 +0900
Branch: REL_11_STABLE [96918b76f] 2021-05-25 10:11:21 +0900
Branch: REL_10_STABLE [c64b5d10d] 2021-05-25 10:11:26 +0900
Branch: REL9_6_STABLE [7777df34d] 2021-05-25 10:11:33 +0900
-->
     <para>
      Disallow SSL renegotiation more completely (Michael Paquier)
     </para>

     <para>
      SSL renegotiation has been disabled for some time, but the server
      would still cooperate with a client-initiated renegotiation request.
      A maliciously crafted renegotiation request could result in a server
      crash (see OpenSSL issue CVE-2021-3449).  Disable the feature
      altogether on OpenSSL versions that permit doing so, which are
      1.1.0h and newer.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [84f5c2908] 2021-05-21 14:03:59 -0400
Branch: REL_13_STABLE [d18ee6f92] 2021-05-21 14:03:53 -0400
Branch: REL_12_STABLE [41c6a5bec] 2021-05-21 14:03:53 -0400
Branch: REL_11_STABLE [ef9480509] 2021-05-21 14:03:53 -0400
Branch: master Release: REL_14_BR [3a09d75b4] 2021-06-10 12:27:27 -0400
Branch: REL_13_STABLE [6e43f1c2d] 2021-06-10 12:27:27 -0400
Branch: REL_12_STABLE [26383da7d] 2021-06-10 12:27:27 -0400
Branch: REL_11_STABLE [eea081ad0] 2021-06-10 12:27:27 -0400
Branch: master Release: REL_14_BR [d102aafb6] 2021-06-22 17:48:39 -0400
Branch: REL_13_STABLE [6f1321d5a] 2021-06-22 17:48:39 -0400
Branch: REL_12_STABLE [29d5d5761] 2021-06-22 17:48:39 -0400
Branch: REL_11_STABLE [77200c569] 2021-06-22 17:48:39 -0400
Branch: master [ef12f32c0] 2021-07-31 11:50:14 -0400
Branch: REL_14_STABLE [ec410c985] 2021-07-31 11:50:14 -0400
Branch: REL_13_STABLE [93f99693f] 2021-07-31 11:50:14 -0400
Branch: REL_12_STABLE [f26043645] 2021-07-31 11:50:14 -0400
Branch: REL_11_STABLE [cefb1230e] 2021-07-31 11:50:14 -0400
Branch: master Release: REL_14_BR [f21fadafa] 2021-05-20 18:32:37 -0400
Branch: REL_13_STABLE [c64183f23] 2021-05-20 18:32:37 -0400
Branch: REL_12_STABLE [8d341d6cb] 2021-05-20 18:32:37 -0400
Branch: REL_11_STABLE [0c1b2cb17] 2021-05-20 18:32:37 -0400
-->
     <para>
      Restore the Portal-level snapshot after <command>COMMIT</command>
      or <command>ROLLBACK</command> within a procedure (Tom Lane)
     </para>

     <para>
      This change fixes cases where an attempt to fetch a toasted value
      immediately after <command>COMMIT</command>/<command>ROLLBACK</command>
      would fail with errors like <quote>no known snapshots</quote> or
      <quote>missing chunk number 0 for toast value</quote>.
     </para>

     <para>
      Some extensions may attempt to execute SQL code outside of any
      Portal.  They are responsible for ensuring that an outer snapshot
      exists before doing so.  Previously, not providing a snapshot might
      work or it might not; now it will consistently fail
      with <quote>cannot execute SQL without an outer snapshot or
      portal</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [ba2c6d6ce] 2021-06-08 17:50:29 -0400
Branch: REL_13_STABLE [c1fd756fd] 2021-06-08 17:50:15 -0400
Branch: REL_12_STABLE [c3b508268] 2021-06-08 17:50:15 -0400
Branch: REL_11_STABLE [2757865fa] 2021-06-08 17:50:15 -0400
Branch: master Release: REL_14_BR [be9009890] 2021-06-08 18:40:06 -0400
Branch: REL_13_STABLE [c5b281841] 2021-06-08 18:40:06 -0400
Branch: REL_12_STABLE [182323300] 2021-06-08 18:40:06 -0400
Branch: REL_11_STABLE [5b7bf9f72] 2021-06-08 18:40:06 -0400
-->
     <para>
      Avoid misbehavior when persisting the output of a cursor that's
      reading a non-stable query (Tom Lane)
     </para>

     <para>
      Previously, we'd always rewind and re-read the whole query result,
      possibly getting results different from the earlier execution,
      causing great confusion later.  For a NO SCROLL cursor, we can fix
      this by only storing the not-yet-read portion of the query output,
      which is sufficient since a NO SCROLL cursor can't be backed up.
      Cursors with the SCROLL option remain at hazard, but that was
      already documented to be an unsafe option to use with a non-stable
      query.  Make those documentation warnings stronger.
     </para>

     <para>
      Also force NO SCROLL mode for the implicit cursor used by
      a <application>PL/pgSQL</application> FOR-over-query loop,
      to avoid this type of problem when persisting such a cursor
      during an intra-procedure commit.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [1103033ae] 2021-06-01 11:12:56 -0400
Branch: REL_13_STABLE [e5b0fffa1] 2021-06-01 11:12:56 -0400
Branch: REL_12_STABLE [762fe98b1] 2021-06-01 11:12:56 -0400
Branch: REL_11_STABLE [dc272157a] 2021-06-01 11:12:56 -0400
Branch: REL_10_STABLE [39862dde4] 2021-06-01 11:12:56 -0400
Branch: REL9_6_STABLE [3eca18522] 2021-06-01 11:12:56 -0400
-->
     <para>
      Reject <literal>SELECT ... GROUP BY GROUPING SETS (()) FOR
      UPDATE</literal> (Tom Lane)
     </para>

     <para>
      This should be disallowed, just as <literal>FOR UPDATE</literal>
      with a plain <literal>GROUP BY</literal> is disallowed, but the test
      for that failed to handle empty grouping sets correctly.
      The end result would be a null-pointer dereference in the executor.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a9da1934e] 2021-07-09 11:02:26 -0400
Branch: REL_14_STABLE [39b6e85f1] 2021-07-09 11:02:26 -0400
Branch: REL_13_STABLE [6edccac16] 2021-07-09 11:02:26 -0400
Branch: REL_12_STABLE [9c729bd30] 2021-07-09 11:02:26 -0400
Branch: REL_11_STABLE [158594f99] 2021-07-09 11:02:26 -0400
Branch: REL_10_STABLE [51df19a05] 2021-07-09 11:02:26 -0400
Branch: REL9_6_STABLE [f0271cb15] 2021-07-09 11:02:26 -0400
-->
     <para>
      Reject cases where a query in <literal>WITH</literal>
      rewrites to just <command>NOTIFY</command> (Tom Lane)
     </para>

     <para>
      Such cases previously crashed.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [e7fc488ad] 2021-07-10 12:42:59 +0100
Branch: REL_14_STABLE [06883d58f] 2021-07-10 12:45:00 +0100
Branch: REL_13_STABLE [f23a9b8a4] 2021-07-10 12:46:13 +0100
Branch: REL_12_STABLE [357b66ef9] 2021-07-10 12:47:45 +0100
Branch: REL_11_STABLE [5763ef42c] 2021-07-10 12:48:59 +0100
Branch: REL_10_STABLE [54a0ec1bd] 2021-07-10 12:50:05 +0100
Branch: REL9_6_STABLE [f8abf6944] 2021-07-10 12:51:22 +0100
-->
     <para>
      In <type>numeric</type> multiplication, round the result rather than
      failing if it would have more than 16383 digits after the decimal
      point (Dean Rasheed)
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [4dd5ce2fd] 2021-07-31 11:21:44 +0100
Branch: REL_14_STABLE [0d6b87497] 2021-07-31 11:23:48 +0100
Branch: REL_13_STABLE [053ec4e0c] 2021-07-31 11:25:39 +0100
Branch: REL_12_STABLE [5c62920fa] 2021-07-31 11:27:02 +0100
Branch: REL_11_STABLE [dcd0ab672] 2021-07-31 11:28:10 +0100
Branch: REL_10_STABLE [39b0bda67] 2021-07-31 11:29:50 +0100
Branch: REL9_6_STABLE [5cf350ce0] 2021-07-31 11:31:18 +0100
Branch: REL_11_STABLE [434ddfb79] 2021-08-05 22:24:28 +0100
Branch: master [2642df9fa] 2021-08-06 21:29:15 +0100
Branch: REL_14_STABLE [032556570] 2021-08-06 21:30:25 +0100
Branch: REL_13_STABLE [da188b993] 2021-08-06 21:31:20 +0100
Branch: REL_12_STABLE [cc4420f88] 2021-08-06 21:31:58 +0100
Branch: REL_11_STABLE [7a9c9acfe] 2021-08-06 21:32:46 +0100
Branch: REL_10_STABLE [f20b6bc96] 2021-08-06 21:33:25 +0100
Branch: REL9_6_STABLE [5b7b92ad7] 2021-08-06 21:34:04 +0100
-->
     <para>
      Fix corner-case errors and loss of precision when
      raising <type>numeric</type> values to very large powers
      (Dean Rasheed)
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [226ec49ff] 2021-08-05 09:24:11 +0100
Branch: REL_14_STABLE [ecbdbdfd9] 2021-08-05 09:27:35 +0100
Branch: REL_13_STABLE [a72ad6315] 2021-08-05 09:29:13 +0100
Branch: REL_12_STABLE [43644bd3b] 2021-08-05 09:30:37 +0100
Branch: REL_11_STABLE [4851940a5] 2021-08-05 09:32:03 +0100
Branch: REL_10_STABLE [661558bc3] 2021-08-05 09:33:55 +0100
Branch: REL9_6_STABLE [ed3e1663c] 2021-08-05 09:35:46 +0100
-->
     <para>
      Fix division-by-zero failure in <function>to_char()</function>
      with <literal>EEEE</literal> format and a <type>numeric</type> input
      value less than 10^(-1001) (Dean Rasheed)
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [55fe60938] 2021-07-09 14:04:30 +1200
Branch: REL_14_STABLE [6de3a21bb] 2021-07-09 14:04:40 +1200
Branch: REL_13_STABLE [6f88b68ff] 2021-07-09 14:04:49 +1200
Branch: REL_12_STABLE [efc42a1e1] 2021-07-09 14:04:56 +1200
Branch: REL_11_STABLE [45bad6a39] 2021-07-09 14:05:05 +1200
Branch: REL_10_STABLE [1efcd5720] 2021-07-09 14:05:15 +1200
Branch: REL9_6_STABLE [674ee3b76] 2021-07-09 14:05:24 +1200
Branch: REL_13_STABLE [87103002c] 2021-07-09 15:12:31 +1200
Branch: REL_12_STABLE [b18621139] 2021-07-09 15:13:01 +1200
Branch: REL_11_STABLE [137af4f27] 2021-07-09 15:13:29 +1200
Branch: REL_10_STABLE [dd76aa54a] 2021-07-09 15:14:01 +1200
Branch: REL9_6_STABLE [3e474a708] 2021-07-09 15:14:26 +1200
-->
     <para>
      Fix <function>pg_size_pretty(bigint)</function> to round negative
      values consistently with the way it rounds positive ones (and
      consistently with the <type>numeric</type> version) (Dean Rasheed,
      David Rowley)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [1250aad42] 2021-06-12 13:29:24 -0400
Branch: REL_13_STABLE [f479ea94b] 2021-06-12 13:29:24 -0400
Branch: REL_12_STABLE [7681b78fb] 2021-06-12 13:29:24 -0400
Branch: REL_11_STABLE [25d1ef1aa] 2021-06-12 13:29:24 -0400
Branch: REL_10_STABLE [26a053533] 2021-06-12 13:29:24 -0400
Branch: REL9_6_STABLE [c1ffbbcbc] 2021-06-12 13:29:24 -0400
-->
     <para>
      Make <literal>pg_filenode_relation(0, 0)</literal> return NULL
      rather than failing (Justin Pryzby)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [626731db2] 2021-07-11 12:54:24 -0400
Branch: REL_14_STABLE [69dfc36fd] 2021-07-11 12:54:24 -0400
Branch: REL_13_STABLE [1c612bc98] 2021-07-11 12:54:24 -0400
Branch: REL_12_STABLE [92340ba5a] 2021-07-11 12:54:24 -0400
Branch: REL_11_STABLE [6bd9ae173] 2021-07-11 12:54:24 -0400
Branch: REL_10_STABLE [1d49c8887] 2021-07-11 12:54:24 -0400
Branch: REL9_6_STABLE [734be249d] 2021-07-11 12:54:24 -0400
-->
     <para>
      Make <command>ALTER EXTENSION</command> lock the extension when
      adding or removing a member object (Tom Lane)
     </para>

     <para>
      The previous coding allowed <command>ALTER EXTENSION
      ADD/DROP</command> to occur concurrently with <command>DROP
      EXTENSION</command>, leading to a crash or corrupt catalog entries.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [29abde637] 2021-07-19 10:36:15 +0530
Branch: REL_14_STABLE [40295d158] 2021-07-19 10:54:21 +0530
Branch: REL_13_STABLE [bfa2a926d] 2021-07-19 11:04:21 +0530
Branch: REL_12_STABLE [f2f459f18] 2021-07-19 11:15:03 +0530
Branch: REL_11_STABLE [eb158e74a] 2021-07-19 11:23:35 +0530
Branch: REL_10_STABLE [22fd784af] 2021-07-19 11:32:08 +0530
-->
     <para>
      Fix <command>ALTER SUBSCRIPTION</command> to reject an empty slot
      name (Japin Li)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [df80fa2ee] 2021-07-16 13:01:43 -0400
Branch: REL_14_STABLE [eef92de11] 2021-07-16 13:01:43 -0400
Branch: REL_13_STABLE [c31516ae5] 2021-07-16 13:01:43 -0400
Branch: REL_12_STABLE [7584ec1f6] 2021-07-16 13:01:43 -0400
Branch: REL_11_STABLE [fed35bd4a] 2021-07-16 13:01:43 -0400
-->
     <para>
      When cloning a partitioned table's triggers to a new partition,
      ensure that their enabled status is copied
      (&Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9179a82d7] 2021-08-07 13:29:32 -0400
Branch: REL_14_STABLE [2c915905e] 2021-08-07 13:29:32 -0400
Branch: REL_13_STABLE [ba9f665a4] 2021-08-07 13:29:32 -0400
Branch: REL_12_STABLE [1ff1e4a60] 2021-08-07 13:29:32 -0400
Branch: REL_11_STABLE [d33fc4110] 2021-08-07 13:29:32 -0400
Branch: REL_10_STABLE [ac818984a] 2021-08-07 13:29:32 -0400
Branch: REL9_6_STABLE [c08b3a9eb] 2021-08-07 13:29:32 -0400
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_14_BR [187682c32] 2021-06-03 15:28:24 +0900
Branch: REL_13_STABLE [75d66d10e] 2021-06-03 15:28:37 +0900
Branch: REL_12_STABLE [4ceaa760b] 2021-06-03 15:28:41 +0900
Branch: REL_11_STABLE [dbc9dbba5] 2021-06-03 15:28:45 +0900
Branch: REL_10_STABLE [20f70f558] 2021-06-03 15:28:53 +0900
Branch: REL9_6_STABLE [d9525c46c] 2021-06-03 15:29:01 +0900
-->
     <para>
      Avoid alias conflicts in queries generated
      for <command>REFRESH MATERIALIZED VIEW CONCURRENTLY</command>
      (Tom Lane, Bharath Rupireddy)
     </para>

     <para>
      This command failed on materialized views containing columns with
      certain names, notably <structfield>mv</structfield>
      and <structfield>newdata</structfield>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [6310809c4] 2021-07-24 18:35:52 -0400
Branch: REL_14_STABLE [712ba6b8b] 2021-07-24 18:35:52 -0400
Branch: REL_13_STABLE [f47408cdc] 2021-07-24 18:35:52 -0400
Branch: REL_12_STABLE [899785b4f] 2021-07-24 18:35:52 -0400
Branch: REL_11_STABLE [7b2262a21] 2021-07-24 18:35:52 -0400
Branch: REL_10_STABLE [654372169] 2021-07-24 18:35:52 -0400
Branch: REL9_6_STABLE [1861390e6] 2021-07-24 18:35:52 -0400
-->
     <para>
      Fix <command>PREPARE TRANSACTION</command> to check correctly
      for conflicting session-lifespan and transaction-lifespan locks
      (Tom Lane)
     </para>

     <para>
      A transaction cannot be prepared if it has both session-lifespan and
      transaction-lifespan locks on the same advisory-lock ID value.  This
      restriction was not fully checked, which could lead to a PANIC
      during <command>PREPARE TRANSACTION</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [d21fca084] 2021-06-18 18:00:09 -0400
Branch: REL_13_STABLE [33af10c59] 2021-06-18 18:00:09 -0400
Branch: REL_12_STABLE [c58a41605] 2021-06-18 18:00:09 -0400
Branch: REL_11_STABLE [ea5ae3ae1] 2021-06-18 18:00:09 -0400
Branch: REL_10_STABLE [b7e3a4407] 2021-06-18 18:00:09 -0400
Branch: REL9_6_STABLE [0b29b41e5] 2021-06-18 18:00:09 -0400
-->
     <para>
      Fix misbehavior of <command>DROP OWNED BY</command> when the target
      role is listed more than once in an RLS policy (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [5a0f1c8c0] 2021-06-25 13:59:38 -0400
Branch: REL_13_STABLE [ba815f00a] 2021-06-25 13:59:38 -0400
Branch: REL_12_STABLE [f851696a2] 2021-06-25 13:59:38 -0400
Branch: REL_11_STABLE [fea89d64e] 2021-06-25 13:59:38 -0400
Branch: REL_10_STABLE [f5b780c45] 2021-06-25 13:59:38 -0400
Branch: REL9_6_STABLE [9c7a150ae] 2021-06-25 13:59:38 -0400
-->
     <para>
      Skip unnecessary error tests when removing a role from an RLS policy
      during <command>DROP OWNED BY</command> (Tom Lane)
     </para>

     <para>
      Notably, this fixes some cases where it was necessary to be a
      superuser to use <command>DROP OWNED BY</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master Release: REL_14_BR [9f12a3b95] 2020-11-04 15:13:08 +1300
Branch: REL_13_STABLE [6dcb185bf] 2021-06-22 13:21:25 +1200
-->
     <para>
      Re-allow old-style Windows locale names in <command>CREATE
      COLLATION</command> commands (Thomas Munro)
     </para>

     <para>
      Previously we were failing because the operating system can't
      provide version information for such locales.  At some point
      we may decide to require version information, but no such policy
      exists yet, so re-allow the case for now.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [4b1007445] 2021-05-21 15:12:08 -0400
Branch: REL_13_STABLE [849c7971d] 2021-05-21 15:12:19 -0400
Branch: REL_12_STABLE [61feb8670] 2021-05-21 15:12:37 -0400
-->
     <para>
      Disallow whole-row variables in <literal>GENERATED</literal>
      expressions (Tom Lane)
     </para>

     <para>
      Use of a whole-row variable clearly violates the rule that a
      generated column cannot depend on itself, so such cases have no
      well-defined behavior.  The actual behavior frequently included a
      crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [2b0ee126b] 2021-05-21 15:02:06 -0400
Branch: REL_13_STABLE [77e3204ec] 2021-05-21 15:02:07 -0400
Branch: REL_12_STABLE [dfe51ffbe] 2021-05-21 15:02:07 -0400
-->
     <para>
      Fix usage of <structfield>tableoid</structfield>
      in <literal>GENERATED</literal> expressions (Tom Lane)
     </para>

     <para>
      Some code paths failed to provide a valid value for this system
      column while evaluating a <literal>GENERATED</literal> expression.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master Release: REL_14_BR [0a4efdc7e] 2021-06-18 06:51:12 -0400
Branch: REL_13_STABLE [5b6b5e5ee] 2021-06-18 07:44:58 -0400
Branch: REL_12_STABLE [6432bfe8a] 2021-06-18 07:46:21 -0400
Branch: REL_11_STABLE [306c31804] 2021-06-18 07:53:08 -0400
Branch: REL_11_STABLE [0d3b69ae0] 2021-06-18 11:45:45 -0400
-->
     <para>
      Don't store a <quote>fast default</quote> when adding a column to a
      foreign table (Andrew Dunstan)
     </para>

     <para>
      The fast default is useless since no local heap storage exists for
      such a table, but it confused subsequent operations.  In addition to
      suppressing creation of such catalog entries in <command>ALTER
      TABLE</command> commands, adjust the downstream code to cope
      when one is incorrectly present.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_14_BR [83158f74d] 2020-09-14 13:56:41 +0900
Branch: REL_13_STABLE [acb60edf0] 2021-06-28 10:39:09 +0900
Branch: REL_12_STABLE [e52f7cbec] 2021-06-28 10:43:01 +0900
Branch: REL_11_STABLE [08acba558] 2021-06-28 10:43:04 +0900
Branch: REL_10_STABLE [3c465883b] 2021-06-28 10:43:08 +0900
Branch: REL9_6_STABLE [d3d0cbeb6] 2021-06-28 10:43:13 +0900
Branch: master Release: REL_14_BR [09a69f6e2] 2021-06-28 11:17:05 +0900
Branch: REL_13_STABLE [fd7bc10ab] 2021-06-28 11:17:12 +0900
Branch: REL_12_STABLE [ce8949c4b] 2021-06-28 11:17:16 +0900
Branch: REL_11_STABLE [38ca11ade] 2021-06-28 11:17:20 +0900
Branch: REL_10_STABLE [5160d5bb1] 2021-06-28 11:17:25 +0900
Branch: REL9_6_STABLE [21257a8f6] 2021-06-28 11:17:30 +0900
-->
     <para>
      Allow index state flags to be updated transactionally
      (Michael Paquier, Andrey Lepikhov)
     </para>

     <para>
      This avoids failures when dealing with index predicates that aren't
      really immutable.  While that's not considered a supported case, the
      original reason for using a non-transactional update here is long
      gone, so we may as well change it.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_13_STABLE [102f31a20] 2021-06-18 12:09:22 -0400
Branch: REL_12_STABLE [b2c740c42] 2021-06-18 12:09:22 -0400
Branch: REL_11_STABLE [4b8b3562e] 2021-06-18 12:09:22 -0400
Branch: REL_10_STABLE [f172438ef] 2021-06-18 12:09:22 -0400
Branch: REL9_6_STABLE [1a3d30255] 2021-06-18 12:09:22 -0400
-->
     <para>
      Avoid corrupting the plan cache entry when <command>CREATE
      DOMAIN</command> or <command>ALTER DOMAIN</command> appears
      in a cached plan (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [f560209c6] 2020-09-14 12:35:00 -0400
Branch: REL_13_STABLE [4a20de9d9] 2021-06-25 10:46:10 -0400
Branch: REL_12_STABLE [04a476057] 2021-06-25 10:46:10 -0400
Branch: REL_11_STABLE [c39983600] 2021-06-25 10:46:10 -0400
Branch: REL_10_STABLE [4040139f2] 2021-06-25 10:46:10 -0400
-->
     <para>
      Make walsenders show their latest replication commands
      in <structname>pg_stat_activity</structname> (Tom Lane)
     </para>

     <para>
      Previously, a walsender would show its latest SQL command, which was
      confusing if it's now doing some replication operation instead.
      Now we show replication-protocol commands on the same footing as SQL
      commands.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [93a0bf239] 2021-07-27 15:44:12 -0400
Branch: REL_14_STABLE [ad3b40eb2] 2021-07-27 15:44:12 -0400
Branch: REL_13_STABLE [b8f91d7f9] 2021-07-27 15:44:12 -0400
Branch: REL_12_STABLE [6feb229f5] 2021-07-27 15:44:12 -0400
Branch: REL_11_STABLE [ddd1eac99] 2021-07-27 15:44:12 -0400
Branch: REL_10_STABLE [04fa0e11a] 2021-07-27 15:44:12 -0400
Branch: REL9_6_STABLE [85ec6c322] 2021-07-27 15:44:12 -0400
-->
     <para>
      Make
      <structname>pg_settings</structname>.<structfield>pending_restart</structfield>
      show as true when the pertinent entry
      in <filename>postgresql.conf</filename> has been removed
      (&Aacute;lvaro Herrera)
     </para>

     <para>
      <structfield>pending_restart</structfield> correctly showed the case
      where an entry that cannot be changed without a postmaster restart
      has been modified, but not where the entry had been removed
      altogether.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [28d936031] 2021-07-25 14:02:27 -0400
Branch: REL_14_STABLE [b154ee63b] 2021-07-25 14:02:27 -0400
Branch: REL_13_STABLE [2b8f3f5a7] 2021-07-25 14:02:27 -0400
-->
     <para>
      On 64-bit Windows, allow the effective value
      of <varname>work_mem</varname>
      times <varname>hash_mem_multiplier</varname> to exceed 2GB
      (Tom Lane)
     </para>

     <para>
      This allows <varname>hash_mem_multiplier</varname> to be used for
      its intended purpose of preventing large hash aggregations from
      spilling to disk, even when <quote>large</quote> means multiple
      gigabytes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [889592344] 2021-06-02 14:38:14 -0400
Branch: REL_13_STABLE [6753a5b7e] 2021-06-02 14:38:14 -0400
Branch: REL_12_STABLE [bdd096f1a] 2021-06-02 14:38:14 -0400
-->
     <para>
      Fix mis-planning of queries involving regular tables that are
      inheritance children of foreign tables (Amit Langote)
     </para>

     <para>
      <command>SELECT FOR UPDATE</command> and related commands would fail
      with assertion failures or <quote>could not find junk column</quote>
      errors in such cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d23ac62af] 2021-07-09 13:38:24 -0400
Branch: REL_14_STABLE [1d98fdaed] 2021-07-09 13:38:24 -0400
Branch: REL_13_STABLE [9807b9aed] 2021-07-09 13:38:24 -0400
-->
     <para>
      Fix pullup of constant function-in-FROM results when the FROM item
      is marked <literal>LATERAL</literal> (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master Release: REL_14_BR [caba8f0d4] 2021-06-09 16:17:00 -0400
Branch: REL_13_STABLE [082656429] 2021-06-09 16:17:13 -0400
Branch: REL_12_STABLE [5d950c721] 2021-06-09 16:19:52 -0400
Branch: REL_11_STABLE [ca158c168] 2021-06-09 16:20:10 -0400
Branch: REL_10_STABLE [31bda6a22] 2021-06-09 16:20:28 -0400
Branch: REL9_6_STABLE [6eb5b9ae3] 2021-06-09 16:21:14 -0400
Branch: master Release: REL_14_BR [4dcb1d087] 2021-06-10 09:46:08 -0400
Branch: REL_13_STABLE [3465328aa] 2021-06-10 09:47:25 -0400
Branch: REL_12_STABLE [2208d71a0] 2021-06-10 09:34:39 -0400
Branch: REL_11_STABLE [534b9be80] 2021-06-10 09:43:35 -0400
Branch: REL_10_STABLE [1c2c6a9a2] 2021-06-10 09:48:07 -0400
Branch: REL9_6_STABLE [6cd0e55f9] 2021-06-10 09:51:00 -0400
Branch: REL9_6_STABLE [75212a854] 2021-06-09 16:16:21 -0400
Branch: REL_13_STABLE [99a0a2ada] 2021-06-09 12:28:39 -0400
Branch: REL_12_STABLE [6fc2febc2] 2021-06-09 12:29:00 -0400
Branch: REL_11_STABLE [38982b8b7] 2021-06-09 12:30:28 -0400
Branch: REL_10_STABLE [9778a191a] 2021-06-09 12:30:49 -0400
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master Release: REL_14_BR [c3652f976] 2021-06-12 08:43:54 -0400
Branch: REL_13_STABLE [45322bd9b] 2021-06-12 08:51:29 -0400
Branch: REL_12_STABLE [1730a3334] 2021-06-12 08:54:28 -0400
Branch: REL_11_STABLE [8b9e1275c] 2021-06-12 08:55:29 -0400
Branch: REL_10_STABLE [0cd8a55bd] 2021-06-12 08:55:39 -0400
Branch: REL9_6_STABLE [dee7ad20d] 2021-06-12 08:55:55 -0400
Branch: master Release: REL_14_BR [9d97c3408] 2021-06-13 07:19:34 -0400
Branch: REL_13_STABLE [47d5781cb] 2021-06-13 07:19:34 -0400
Branch: REL_12_STABLE [914c716ca] 2021-06-13 07:19:35 -0400
Branch: REL_11_STABLE [8cb3d95c2] 2021-06-13 07:19:36 -0400
Branch: REL_10_STABLE [319d616dd] 2021-06-13 07:19:38 -0400
Branch: REL9_6_STABLE [84cb4be71] 2021-06-13 07:19:40 -0400
Branch: master Release: REL_14_BR [54a5ed220] 2021-06-15 15:35:47 -0400
Branch: REL_13_STABLE [d906d106f] 2021-06-15 15:36:50 -0400
Branch: REL_12_STABLE [fb3d6b0e1] 2021-06-15 15:36:59 -0400
Branch: REL_11_STABLE [c0a758780] 2021-06-15 15:37:07 -0400
Branch: REL_10_STABLE [1dc53c914] 2021-06-15 15:37:15 -0400
Branch: REL9_6_STABLE [e46f6a078] 2021-06-15 15:37:24 -0400
-->
     <para>
      Fix corner-case failure of a new standby to follow a new primary
      (Dilip Kumar, Robert Haas)
     </para>

     <para>
      Under a narrow combination of conditions, the standby could wind up
      trying to follow the wrong WAL timeline.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [a00c138b7] 2021-07-29 01:31:41 +0900
Branch: REL_14_STABLE [f2a3d7404] 2021-07-29 01:33:33 +0900
Branch: REL_13_STABLE [a66b05b42] 2021-07-29 01:34:13 +0900
Branch: REL_12_STABLE [d7ded08e6] 2021-07-29 01:35:00 +0900
Branch: REL_11_STABLE [02ef4d1e2] 2021-07-29 01:35:05 +0900
Branch: REL_10_STABLE [25fe5b2bb] 2021-07-29 01:35:10 +0900
Branch: REL9_6_STABLE [32d182dd0] 2021-07-29 01:35:52 +0900
-->
     <para>
      Update minimum recovery point when WAL replay of a transaction abort
      record causes file truncation (Fujii Masao)
     </para>

     <para>
      File truncation is irreversible, so it's no longer safe to stop
      recovery at a point earlier than that record.  The corresponding
      case for transaction commit was fixed years ago, but this one was
      overlooked.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [ead9e51e8] 2021-07-16 12:07:30 -0400
Branch: REL_14_STABLE [e5bcbb107] 2021-07-16 12:07:30 -0400
Branch: REL_13_STABLE [866237a6f] 2021-07-16 12:07:30 -0400
Branch: master [8589299e0] 2021-07-17 13:19:17 -0400
Branch: REL_14_STABLE [d8f3b021c] 2021-07-17 13:19:17 -0400
Branch: REL_13_STABLE [7099ba058] 2021-07-17 13:19:17 -0400
Branch: master [0d2cb6b2b] 2021-07-19 17:21:07 -0400
Branch: REL_14_STABLE [1e8751380] 2021-07-19 17:21:07 -0400
Branch: REL_13_STABLE [ce413eba4] 2021-07-19 17:21:07 -0400
Branch: master [ce197e91d] 2021-07-29 17:09:06 -0400
Branch: REL_14_STABLE [f951f6f69] 2021-07-29 17:09:06 -0400
Branch: REL_13_STABLE [41d27ee7b] 2021-07-29 17:26:25 -0400
-->
     <para>
      Advance oldest-required-WAL-segment horizon properly after a
      replication slot is invalidated (Kyotaro Horiguchi)
     </para>

     <para>
      If all slots were invalidated, the horizon would not move again,
      eventually allowing the server's WAL storage to run out of space.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [50371df26] 2021-07-02 16:04:54 -0400
Branch: REL_14_STABLE [63a952167] 2021-07-02 16:05:20 -0400
Branch: REL_13_STABLE [7fc97752d] 2021-07-02 16:04:54 -0400
Branch: REL_12_STABLE [feff61557] 2021-07-02 16:04:54 -0400
Branch: REL_11_STABLE [32d50b895] 2021-07-02 16:04:54 -0400
Branch: REL_10_STABLE [0b5089e8c] 2021-07-02 16:04:54 -0400
-->
     <para>
      In walreceivers, avoid attempting catalog lookups after an error
      (Masahiko Sawada, Bharath Rupireddy)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master Release: REL_14_BR [2945a488a] 2020-11-16 18:27:51 +0900
Branch: REL_13_STABLE [8d091922f] 2021-07-25 11:15:30 +0900
Branch: REL_12_STABLE [1bcfda30f] 2021-07-25 11:16:02 +0900
Branch: REL_11_STABLE [9c83398f8] 2021-07-25 11:16:13 +0900
Branch: REL_10_STABLE [710fabfa2] 2021-07-25 11:16:26 +0900
Branch: REL9_6_STABLE [8e5be9cfe] 2021-07-25 11:16:34 +0900
-->
     <para>
      Ensure that a standby server's startup process will respond to a
      shutdown signal promptly while waiting for WAL to arrive (Fujii
      Masao, Soumyadeep Chakraborty)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_14_BR [b786304c2] 2021-06-28 09:29:38 +0530
Branch: REL_13_STABLE [741deb260] 2021-06-28 08:42:48 +0530
Branch: REL_12_STABLE [b75c1f687] 2021-06-28 09:17:10 +0530
Branch: REL_11_STABLE [c62c3769f] 2021-06-28 09:09:42 +0530
-->
     <para>
      Correctly clear shared state after failing to become a member of a
      transaction commit group (Amit Kapila)
     </para>

     <para>
      Given the right timing, this could cause an assertion failure when
      some later session re-uses the same PGPROC object.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master Release: REL_14_BR [b6d8d2073] 2021-06-24 10:45:23 +0300
Branch: REL_13_STABLE [2a0ab13f8] 2021-06-24 10:45:34 +0300
Branch: REL_12_STABLE [caac19650] 2021-06-24 10:45:43 +0300
Branch: REL_11_STABLE [c78bb32c1] 2021-06-24 10:45:46 +0300
Branch: REL_10_STABLE [a5eacd86b] 2021-06-24 10:45:49 +0300
Branch: REL9_6_STABLE [85ae8ccb2] 2021-06-24 10:45:52 +0300
Branch: master Release: REL_14_BR [9b8ed0f52] 2021-06-24 11:19:03 +0300
Branch: REL_13_STABLE [6fb377e5f] 2021-06-24 11:19:31 +0300
Branch: REL_12_STABLE [8b01a403c] 2021-06-24 11:19:34 +0300
Branch: REL_11_STABLE [eb3bd243a] 2021-06-24 11:19:37 +0300
Branch: REL_10_STABLE [fbbc48995] 2021-06-24 11:19:40 +0300
Branch: REL9_6_STABLE [5956795cb] 2021-06-24 11:19:44 +0300
-->
     <para>
      Add locking to avoid reading incorrect relmapper data in the face of
      a concurrent write from another process (Heikki Linnakangas)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master Release: REL_14_BR [5cc1cd502] 2021-06-11 19:07:32 -0400
Branch: REL_13_STABLE [065ce069a] 2021-06-11 19:07:32 -0400
Branch: REL_12_STABLE [0c7efd975] 2021-06-11 19:07:32 -0400
-->
     <para>
      Improve progress reporting for the sort phase of a parallel btree
      index build (Matthias van de Meent)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [fe6a20ce5] 2021-06-12 12:59:15 -0400
Branch: REL_13_STABLE [8b5055812] 2021-06-12 12:59:15 -0400
Branch: REL_12_STABLE [1f280e833] 2021-06-12 12:59:15 -0400
Branch: REL_11_STABLE [9eecea7f3] 2021-06-12 12:59:15 -0400
Branch: REL_10_STABLE [4745c119e] 2021-06-12 12:59:15 -0400
-->
     <para>
      Improve checks for violations of replication protocol (Tom Lane)
     </para>

     <para>
      Logical replication workers frequently used Asserts to check for
      cases that could be triggered by invalid or out-of-order replication
      commands.  This seems unwise, so promote these tests to regular
      error checks.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [ab55d742e] 2021-06-11 16:12:41 -0400
Branch: REL_13_STABLE [b270713fd] 2021-06-11 16:12:36 -0400
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_14_BR [bfd96b7a3] 2021-06-12 15:29:48 +0900
Branch: REL_13_STABLE [fad9c8e93] 2021-06-12 15:30:00 +0900
-->
     <para>
      Fix assorted crash cases in logical replication of partitioned-table
      updates (Amit Langote, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [b39630fd4] 2021-05-22 21:25:29 -0400
Branch: REL_13_STABLE [5b4791b45] 2021-05-22 21:24:48 -0400
-->
     <para>
      Fix potential crash when firing AFTER triggers of partitioned tables
      in logical replication workers (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_14_BR [6d0eb3855] 2021-05-21 07:54:27 +0530
Branch: REL_13_STABLE [c83c0257e] 2021-05-21 08:03:38 +0530
Branch: REL_12_STABLE [18c6242b7] 2021-05-21 08:17:25 +0530
Branch: REL_11_STABLE [71787b23e] 2021-05-21 08:31:10 +0530
-->
     <para>
      Fix deadlock when multiple logical replication workers try to
      truncate the same table (Peter Smith, Haiying Tang)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_14_BR [4daa140a2] 2021-06-15 08:28:36 +0530
Branch: REL_13_STABLE [602a32a68] 2021-06-15 08:41:16 +0530
Branch: REL_12_STABLE [40ad7ebff] 2021-06-15 08:50:12 +0530
Branch: REL_11_STABLE [1f8a934e0] 2021-06-15 09:02:32 +0530
Branch: REL_10_STABLE [35f56c124] 2021-06-15 09:10:24 +0530
Branch: REL9_6_STABLE [43acadfce] 2021-06-15 09:18:38 +0530
Branch: REL_13_STABLE [56e366f67] 2021-06-24 15:21:50 +0530
Branch: REL_12_STABLE [72b51e214] 2021-06-24 15:25:13 +0530
Branch: REL_11_STABLE [e95f617ac] 2021-06-24 15:26:37 +0530
-->
     <para>
      Fix error cases and memory leaks in logical decoding of speculative
      insertions (Dilip Kumar)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master Release: REL_14_BR [eb89cb43a] 2021-06-01 14:27:14 +0530
Branch: REL_13_STABLE [d25056812] 2021-06-01 14:25:19 +0530
Branch: REL_13_STABLE [357cb8f07] 2021-06-18 08:51:18 +0530
-->
     <para>
      Fix memory leak in logical replication output (Amit Langote)
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [dd0e37cc1] 2021-07-10 10:26:38 -0700
Branch: REL_14_STABLE [10a07973c] 2021-07-10 10:27:07 -0700
Branch: REL_13_STABLE [edd9a2bf7] 2021-07-10 10:27:27 -0700
Branch: REL_12_STABLE [5b1621d2f] 2021-07-10 10:28:15 -0700
Branch: REL_11_STABLE [52c168db9] 2021-07-10 10:28:33 -0700
-->
     <para>
      Avoid leaving an invalid record-type hash table entry behind after
      an error (Sait Talha Nisanci)
     </para>

     <para>
      This could lead to later crashes or memory leakage.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [131ea3e90] 2021-06-16 19:30:17 -0400
Branch: REL_13_STABLE [d03a41d1c] 2021-06-16 19:30:17 -0400
Branch: REL_12_STABLE [17d962cca] 2021-06-16 19:30:17 -0400
Branch: REL_11_STABLE [9cf163266] 2021-06-16 19:30:17 -0400
Branch: REL_10_STABLE [a6f7745a3] 2021-06-16 19:30:17 -0400
Branch: REL9_6_STABLE [c50596cdc] 2021-06-16 19:30:17 -0400
-->
     <para>
      Fix plan cache reference leaks in some error cases in
      <command>CREATE TABLE ... AS EXECUTE</command> (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master Release: REL_14_BR [b1d653890] 2021-05-29 15:12:34 +1200
Branch: REL_13_STABLE [d41fda6aa] 2021-05-29 15:13:44 +1200
Branch: REL_12_STABLE [82248f227] 2021-05-29 15:14:53 +1200
Branch: REL_11_STABLE [a15d84470] 2021-05-29 15:16:15 +1200
-->
     <para>
      Fix race condition in code for sharing tuple descriptors across
      parallel workers (Thomas Munro)
     </para>

     <para>
      Given the right timing, a crash could result.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master Release: REL_14_BR [96540f80f] 2021-06-11 12:16:14 -0400
Branch: REL_13_STABLE [218b10100] 2021-06-11 12:16:14 -0400
-->
     <para>
      Fix race condition when invalidating an obsolete replication slot
      concurrently with an attempt to drop or update it (Andres Freund,
      &Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [30d8bad49] 2021-05-15 12:21:06 -0400
Branch: REL_13_STABLE [c3cc73e14] 2021-05-15 12:21:06 -0400
Branch: REL_12_STABLE [6bcb51968] 2021-05-15 12:21:06 -0400
Branch: REL_11_STABLE [6fcbaea7a] 2021-05-15 12:21:06 -0400
Branch: REL_10_STABLE [c76ceacbd] 2021-05-15 12:21:06 -0400
Branch: REL9_6_STABLE [5d195dc40] 2021-05-15 12:21:06 -0400
-->
     <para>
      Fix possible race condition when releasing BackgroundWorkerSlots
      (Tom Lane)
     </para>

     <para>
      It's likely that this doesn't fix any observable bug on Intel
      hardware, but machines with weaker memory ordering rules could
      have problems.
     </para>
    </listitem>

    <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [41469253e] 2021-07-13 12:40:16 +1200
Branch: REL_14_STABLE [a3b8d91cc] 2021-07-13 12:42:04 +1200
Branch: REL_13_STABLE [204f646a2] 2021-07-13 12:42:43 +1200
Branch: REL_12_STABLE [6f1c7a2d0] 2021-07-13 12:44:36 +1200
Branch: REL_11_STABLE [187e9c399] 2021-07-13 12:45:35 +1200
Branch: REL_10_STABLE [b55e478a4] 2021-07-13 12:46:12 +1200
Branch: REL9_6_STABLE [87b7a652b] 2021-07-13 12:46:52 +1200
Branch: master [5bd38d2f2] 2021-07-13 13:27:05 +1200
Branch: REL_14_STABLE [a92709fed] 2021-07-13 13:27:44 +1200
Branch: REL_13_STABLE [2fde8e49a] 2021-07-13 13:28:19 +1200
Branch: REL_12_STABLE [645c5d119] 2021-07-13 13:30:26 +1200
Branch: REL_11_STABLE [eff751ea5] 2021-07-13 13:31:00 +1200
Branch: REL_10_STABLE [d7f10f39c] 2021-07-13 13:31:29 +1200
Branch: REL9_6_STABLE [d0e44bae4] 2021-07-13 13:32:10 +1200
-->
     <para>
      Fix latent crash in sorting code (Ronan Dunklau)
     </para>

     <para>
      One code path could attempt to free a null pointer.  The case
      appears unreachable in the core server's use of sorting, but perhaps
      it could be triggered by extensions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master Release: REL_14_BR [8f72bbac3] 2021-05-14 15:08:02 -0700
Branch: REL_13_STABLE [fa675af59] 2021-05-14 15:08:00 -0700
-->
     <para>
      Harden B-tree posting list split code against corrupt data
      (Peter Geoghegan)
     </para>

     <para>
      Throw an error, rather than crashing, for an attempt to insert an
      item with a TID identical to an existing entry.  While that
      shouldn't ever happen, it has been reported to happen when the index
      is inconsistent with its table.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [c3c35a733] 2021-05-14 15:07:34 -0400
Branch: REL_13_STABLE [dc714c120] 2021-05-14 15:07:34 -0400
Branch: REL_12_STABLE [4e046281f] 2021-05-14 15:07:34 -0400
Branch: REL_11_STABLE [d776045eb] 2021-05-14 15:07:34 -0400
Branch: REL_10_STABLE [e87a0d2e0] 2021-05-14 15:07:34 -0400
Branch: REL9_6_STABLE [5015d3c35] 2021-05-14 15:07:34 -0400
-->
     <para>
      Prevent infinite loops in SP-GiST index insertion (Tom Lane)
     </para>

     <para>
      In the event that INCLUDE columns take up enough space to prevent a
      leaf index tuple from ever fitting on a page, the text_ops operator
      class would get into an infinite loop vainly trying to make the
      tuple fit.
      While pre-v11 versions don't have INCLUDE columns, back-patch this
      anti-looping fix to them anyway, as it seems like a good defense
      against bugs in operator classes.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [eb7a6b922] 2021-05-14 13:29:39 -0400
Branch: REL_13_STABLE [c1b72bf04] 2021-05-14 13:26:55 -0400
Branch: REL_12_STABLE [004288d3c] 2021-05-14 13:26:55 -0400
Branch: REL_11_STABLE [f4ee4082f] 2021-05-14 13:26:55 -0400
Branch: REL_10_STABLE [fe64adc93] 2021-05-14 13:26:55 -0400
Branch: REL9_6_STABLE [4c6cfcc37] 2021-05-14 13:26:55 -0400
Branch: master Release: REL_14_BR [e47f93f98] 2021-05-14 13:29:39 -0400
Branch: REL_13_STABLE [63831c162] 2021-05-14 12:54:26 -0400
Branch: REL_12_STABLE [4c646b179] 2021-05-14 12:54:26 -0400
Branch: REL_11_STABLE [8274f4517] 2021-05-14 12:54:26 -0400
Branch: REL_10_STABLE [39b8ccb08] 2021-05-14 12:54:26 -0400
Branch: REL9_6_STABLE [567328989] 2021-05-14 12:54:26 -0400
-->
     <para>
      Ensure that SP-GiST index insertion can be terminated by a query
      cancel request (Tom Lane, &Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d9809bf86] 2021-07-20 13:01:48 -0400
Branch: REL_14_STABLE [899564e01] 2021-07-20 13:01:48 -0400
Branch: REL_13_STABLE [0fce76b99] 2021-07-20 13:01:48 -0400
Branch: REL_12_STABLE [85189f54a] 2021-07-20 13:01:48 -0400
Branch: REL_11_STABLE [7321d5c3f] 2021-07-20 13:01:48 -0400
Branch: REL_10_STABLE [4eac891b1] 2021-07-20 13:01:48 -0400
Branch: REL9_6_STABLE [dffec69fe] 2021-07-20 13:01:48 -0400
-->
     <para>
      Fix uninitialized-variable bug that could
      cause <application>PL/pgSQL</application> to act as though
      an <literal>INTO</literal> clause
      specified <literal>STRICT</literal>, even though it didn't
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [6f5d9bce5] 2021-06-28 14:17:41 -0400
Branch: REL_14_STABLE [cf1f545bf] 2021-06-28 14:17:42 -0400
Branch: REL_13_STABLE [1603deca3] 2021-06-28 14:17:42 -0400
Branch: REL_12_STABLE [240d56fc4] 2021-06-28 14:17:42 -0400
Branch: REL_11_STABLE [34c24e5a4] 2021-06-28 14:17:42 -0400
Branch: REL_10_STABLE [06a2b2fe5] 2021-06-28 14:17:42 -0400
Branch: REL9_6_STABLE [b54be47cd] 2021-06-28 14:17:42 -0400
-->
     <para>
      Don't abort the process for an out-of-memory failure in libpq's
      printing functions (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: John Naylor <john.naylor@postgresql.org>
Branch: master [5fcf3945b] 2021-07-30 15:39:22 -0400
Branch: REL_14_STABLE [f051b87ac] 2021-07-30 16:28:43 -0400
Branch: REL_13_STABLE [171bf1cea] 2021-07-30 16:18:59 -0400
Branch: REL_12_STABLE [d9589eb62] 2021-07-30 15:59:10 -0400
Branch: REL_11_STABLE [c7181a32c] 2021-07-30 16:12:17 -0400
Branch: REL_10_STABLE [231c19a89] 2021-07-30 16:40:42 -0400
Branch: REL9_6_STABLE [cfcb0ceab] 2021-07-30 16:34:33 -0400
Branch: REL_11_STABLE [9455e7f50] 2021-07-30 18:54:38 -0400
Branch: REL_10_STABLE [f3cd6aeb8] 2021-07-30 18:54:10 -0400
Branch: REL9_6_STABLE [fa27389c5] 2021-07-30 18:52:55 -0400
-->
     <para>
      In <application>ecpg</application>, allow the <type>numeric</type>
      value <systemitem>INT_MIN</systemitem> (usually -2147483648) to be
      converted to integer (John Naylor)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [42f94f56b] 2021-06-07 14:15:25 -0400
Branch: REL_13_STABLE [5b6436874] 2021-06-07 14:15:25 -0400
Branch: REL_12_STABLE [fc896f45d] 2021-06-07 14:15:25 -0400
Branch: REL_11_STABLE [89a5499ef] 2021-06-07 14:15:25 -0400
Branch: REL_10_STABLE [4826fe4c5] 2021-06-07 14:15:25 -0400
Branch: REL9_6_STABLE [ac600c541] 2021-06-07 14:15:25 -0400
Branch: REL_10_STABLE [0b116346b] 2021-06-07 13:12:35 -0400
Branch: REL9_6_STABLE [7cdb97632] 2021-06-07 13:12:35 -0400
-->
     <para>
      In <application>psql</application> and other client programs, avoid
      overrunning the ends of strings when dealing with invalidly-encoded
      data (Tom Lane)
     </para>

     <para>
      An incorrectly-encoded multibyte character near the end of a string
      could cause various processing loops to run past the string's
      terminating NUL, with results ranging from no detectable issue to
      a program crash, depending on what happens to be in the following
      memory.  This is reminiscent of CVE-2006-2313, although these
      particular cases do not appear to have interesting security
      consequences.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [f0e21f2f6] 2021-07-16 17:29:22 -0400
Branch: REL_14_STABLE [3c5b7c628] 2021-07-16 17:29:22 -0400
Branch: REL_13_STABLE [cc340af33] 2021-07-16 17:29:22 -0400
Branch: REL_12_STABLE [5992c94dc] 2021-07-16 17:29:22 -0400
Branch: REL_11_STABLE [ccfc3cbb3] 2021-07-16 17:29:22 -0400
-->
     <para>
      Fix <application>pg_dump</application> to correctly handle triggers
      on partitioned tables whose enabled status is different from their
      parent triggers' status
      (Justin Pryzby, &Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [f807e3410] 2021-06-13 14:32:42 -0400
Branch: REL_13_STABLE [bc7885b7f] 2021-06-13 14:32:42 -0400
Branch: REL_12_STABLE [b7c5823ac] 2021-06-13 14:32:42 -0400
Branch: REL_11_STABLE [73fa76241] 2021-06-13 14:32:42 -0400
Branch: REL_10_STABLE [05fccab6a] 2021-06-13 14:32:42 -0400
Branch: REL9_6_STABLE [dd53b46c7] 2021-06-13 14:32:42 -0400
-->
     <para>
      Avoid <quote>invalid creation date in header</quote> warnings
      observed when running <application>pg_restore</application> on an
      archive file created in a different time zone (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Bruce Momjian <bruce@momjian.us>
Branch: master [74cf7d46a] 2021-07-26 22:38:15 -0400
Branch: REL_14_STABLE [695b4a113] 2021-07-26 22:38:14 -0400
Branch: REL_13_STABLE [0a5e708e2] 2021-07-26 22:38:14 -0400
Branch: REL_12_STABLE [7626e9f2b] 2021-07-26 22:38:14 -0400
Branch: REL_11_STABLE [c4ba87f52] 2021-07-26 22:38:14 -0400
Branch: REL_10_STABLE [71121450e] 2021-07-26 22:38:14 -0400
Branch: REL9_6_STABLE [088dbf3bc] 2021-07-26 22:38:14 -0400
-->
     <para>
      Make <application>pg_upgrade</application> carry forward the old
      installation's <literal>oldestXID</literal> value (Bertrand Drouvot)
     </para>

     <para>
      Previously, the new installation's <literal>oldestXID</literal> was
      set to a value old enough to (usually) force immediate
      anti-wraparound autovacuuming.  That's not desirable from a
      performance standpoint; what's worse, installations using large
      values of <varname>autovacuum_freeze_max_age</varname> could suffer
      unwanted forced shutdowns soon after an upgrade.
     </para>
    </listitem>

    <listitem>
<!--
Author: Bruce Momjian <bruce@momjian.us>
Branch: master [e462856a7] 2021-08-03 11:58:15 -0400
Branch: REL_14_STABLE [4051a7775] 2021-08-03 11:58:15 -0400
Branch: REL_13_STABLE [a81c71e3a] 2021-08-03 11:58:15 -0400
Branch: REL_12_STABLE [49e319cea] 2021-08-03 11:58:15 -0400
Branch: REL_11_STABLE [3d2b6cd6f] 2021-08-03 11:58:14 -0400
Branch: REL_10_STABLE [58974a542] 2021-08-03 11:58:14 -0400
Branch: REL9_6_STABLE [5e531bb1d] 2021-08-03 11:58:14 -0400
Branch: master [9e51cc87f] 2021-08-03 12:26:08 -0400
Branch: REL_14_STABLE [3a0ba31a3] 2021-08-03 12:26:08 -0400
Branch: REL_13_STABLE [47a573d91] 2021-08-03 12:26:08 -0400
Branch: REL_12_STABLE [165506217] 2021-08-03 12:26:08 -0400
Branch: REL_11_STABLE [554a7648e] 2021-08-03 12:26:08 -0400
Branch: REL_10_STABLE [fcdc461f5] 2021-08-03 12:26:08 -0400
Branch: REL9_6_STABLE [3ab496ab8] 2021-08-03 12:26:08 -0400
-->
     <para>
      Extend <application>pg_upgrade</application> to detect and warn
      about extensions that should be upgraded (Bruce Momjian)
     </para>

     <para>
      A script file is now produced containing the <command>ALTER
      EXTENSION UPDATE</command> commands needed to bring extensions up to
      the versions that are considered default in the new installation.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [7fbe0c8c4] 2021-07-20 12:12:39 +0900
Branch: REL_14_STABLE [3a0d2d0cb] 2021-07-20 12:12:47 +0900
Branch: REL_13_STABLE [fb2b86015] 2021-07-20 12:12:51 +0900
Branch: REL_12_STABLE [b9a0de15e] 2021-07-20 12:12:54 +0900
Branch: REL_11_STABLE [795a9166e] 2021-07-20 12:12:57 +0900
Branch: REL_10_STABLE [11dbad74c] 2021-07-20 12:13:01 +0900
Branch: master [4ef64c425] 2021-07-26 11:13:37 +0900
Branch: REL_14_STABLE [b0d286719] 2021-07-26 11:14:08 +0900
Branch: REL_13_STABLE [2c7395aad] 2021-07-26 11:14:11 +0900
Branch: REL_12_STABLE [c4ef3b81b] 2021-07-26 11:14:14 +0900
Branch: REL_11_STABLE [9c6fa3403] 2021-07-26 11:14:17 +0900
Branch: REL_10_STABLE [4372f0685] 2021-07-26 11:14:21 +0900
-->
     <para>
      Avoid problems when
      switching <application>pg_receivewal</application> between
      compressed and non-compressed WAL storage (Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [aa769f80e] 2021-08-05 20:00:00 +0900
Branch: REL_14_STABLE [588d3f597] 2021-08-05 20:00:01 +0900
Branch: REL_13_STABLE [388a81bf4] 2021-08-05 20:00:02 +0900
Branch: REL_12_STABLE [bbc0cd8fa] 2021-08-05 20:00:04 +0900
-->
     <para>
      Fix <filename>contrib/postgres_fdw</filename> to work usefully with
      generated columns (Etsuro Fujita)
     </para>

     <para>
      <filename>postgres_fdw</filename> will now behave reasonably with
      generated columns, so long as a generated column in a foreign table
      represents a generated column in the remote table.  <command>IMPORT
      FOREIGN SCHEMA</command> will now import generated columns that way
      by default.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c7b7311f6] 2021-07-06 12:36:12 -0400
Branch: REL_14_STABLE [86d491421] 2021-07-06 12:36:12 -0400
Branch: REL_13_STABLE [bee18616a] 2021-07-06 12:36:13 -0400
Branch: REL_12_STABLE [bd2e68d0b] 2021-07-06 12:36:13 -0400
Branch: REL_11_STABLE [a9460dbf1] 2021-07-06 12:36:13 -0400
Branch: REL_10_STABLE [b23ac5aef] 2021-07-06 12:36:13 -0400
Branch: REL9_6_STABLE [67f925bbd] 2021-07-06 12:36:13 -0400
-->
     <para>
      In <filename>contrib/postgres_fdw</filename>, avoid attempting
      catalog lookups after an error (Tom Lane)
     </para>

     <para>
      While this usually worked, it's not very safe since the error might
      have been one that made catalog access nonfunctional.  A side effect
      of the fix is that messages about data conversion errors will now
      mention the query's table and column aliases (if used) rather than
      the true underlying name of a foreign table or column.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [741d7f104] 2021-06-22 21:43:12 -0400
Branch: REL_13_STABLE [e2cde85ef] 2021-06-22 21:43:12 -0400
Branch: REL_12_STABLE [f228c401b] 2021-06-22 21:43:12 -0400
Branch: REL_11_STABLE [a1417e437] 2021-06-22 21:43:12 -0400
Branch: REL_10_STABLE [1f32b789d] 2021-06-22 21:43:12 -0400
Branch: REL9_6_STABLE [13f3fd9e4] 2021-06-22 21:43:12 -0400
Branch: master Release: REL_14_BR [4a054069a] 2021-06-23 11:13:00 -0400
Branch: REL_13_STABLE [b961bdfe1] 2021-06-23 11:12:31 -0400
Branch: REL_12_STABLE [d7da3ef08] 2021-06-23 11:12:31 -0400
Branch: REL_11_STABLE [b1aa0f228] 2021-06-23 11:12:31 -0400
Branch: REL_10_STABLE [0a8929ca0] 2021-06-23 11:12:31 -0400
Branch: REL9_6_STABLE [e535a8899] 2021-06-23 11:12:32 -0400
Branch: master Release: REL_14_BR [a443c1b2d] 2021-06-23 18:41:39 -0400
Branch: REL_13_STABLE [5179a1ab7] 2021-06-23 18:41:39 -0400
Branch: REL_12_STABLE [35e6b3bbf] 2021-06-23 18:41:39 -0400
Branch: REL_11_STABLE [94d8d8d89] 2021-06-23 18:41:39 -0400
Branch: REL_10_STABLE [5cb74a803] 2021-06-23 18:41:39 -0400
Branch: REL9_6_STABLE [ad9827a90] 2021-06-23 18:41:39 -0400
Branch: REL_12_STABLE [7a48dfbb8] 2021-06-24 11:30:32 -0400
Branch: REL_11_STABLE [c6cb62f61] 2021-06-24 11:30:32 -0400
Branch: REL_10_STABLE [024e064af] 2021-06-24 11:30:32 -0400
Branch: REL9_6_STABLE [e0a7036e1] 2021-06-24 11:30:32 -0400
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_13_BR [989d23b04] 2019-08-24 11:45:05 +0900
Branch: master Release: REL_13_BR [06fdc4e4d] 2019-08-24 12:34:37 +0900
Branch: REL_12_STABLE [96f3661e4] 2021-06-17 11:57:21 +0900
Branch: REL_11_STABLE [8f3229942] 2021-06-17 11:57:26 +0900
Branch: REL_10_STABLE [feac82fa8] 2021-06-17 11:57:35 +0900
Branch: REL9_6_STABLE [484c81bf7] 2021-06-17 11:57:44 +0900
Branch: master Release: REL_13_BR [9903338b5] 2019-08-24 11:35:43 +0900
Branch: REL_12_STABLE [a8f687927] 2021-06-17 11:01:16 +0900
Branch: REL_11_STABLE [834cb7269] 2021-06-17 11:01:20 +0900
Branch: REL_10_STABLE [0ed218048] 2021-06-17 11:01:25 +0900
Branch: REL9_6_STABLE [b7cd5c5b0] 2021-06-17 11:01:32 +0900
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [642c0697c] 2021-06-27 12:45:04 -0400
Branch: REL_13_STABLE [2d0944865] 2021-06-27 12:45:04 -0400
Branch: REL_12_STABLE [bc031cf13] 2021-06-27 12:45:04 -0400
Branch: REL_11_STABLE [1acab1209] 2021-06-27 12:45:04 -0400
Branch: REL_10_STABLE [7676d9594] 2021-06-27 12:45:04 -0400
Branch: REL9_6_STABLE [de589c112] 2021-06-27 12:45:04 -0400
-->
     <para>
      Improve the isolation-test infrastructure (Tom Lane, Michael Paquier)
     </para>

     <para>
      Allow isolation test steps to be annotated to show the expected
      completion order.  This allows getting stable results from
      otherwise-racy test cases, without the long delays that we
      previously used (not entirely successfully) to fend off race
      conditions.
      Allow non-quoted identifiers as isolation test session/step names
      (formerly, all such names had to be double-quoted).
      Detect and warn about unused steps in isolation tests.
      Improve display of query results in isolation tests.
      Remove isolationtester's <quote>dry-run</quote> mode.
      Remove memory leaks in isolationtester itself.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9753324b7] 2021-07-05 16:51:57 -0400
Branch: REL_14_STABLE [07f1e0696] 2021-07-05 16:51:57 -0400
Branch: REL_13_STABLE [2f487116e] 2021-07-05 16:51:57 -0400
Branch: REL_12_STABLE [3edc2dbc0] 2021-07-05 16:51:57 -0400
Branch: REL_11_STABLE [76c23bbb4] 2021-07-05 16:51:57 -0400
Branch: REL_10_STABLE [8c3e36fcc] 2021-07-05 16:51:57 -0400
Branch: REL9_6_STABLE [b82eabec3] 2021-07-05 16:51:57 -0400
Branch: master Release: REL_14_BR [e135743ef] 2021-05-11 20:59:58 -0400
Branch: REL_13_STABLE [834d9284b] 2021-05-11 20:59:45 -0400
-->
     <para>
      Reduce overhead of cache-clobber testing (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master Release: REL_14_BR [4a682d85a] 2021-06-05 07:16:34 +0200
Branch: REL_13_STABLE [3989f8fb9] 2021-06-17 09:01:22 +0200
Branch: REL_12_STABLE [9438962ce] 2021-06-17 09:02:20 +0200
Branch: REL_11_STABLE [1a2752be8] 2021-06-17 09:02:44 +0200
Branch: REL_10_STABLE [6b6fbfd7e] 2021-06-17 09:03:30 +0200
Branch: REL9_6_STABLE [9c31e4165] 2021-06-17 09:04:15 +0200
Branch: REL_12_STABLE [70293e946] 2021-06-17 16:39:13 +0200
Branch: REL_11_STABLE [ba529a6ff] 2021-06-18 06:51:56 +0200
Branch: REL_10_STABLE [91709e10a] 2021-06-18 06:52:46 +0200
Branch: REL9_6_STABLE [ec52b886d] 2021-06-18 06:52:48 +0200
-->
     <para>
      Fix <application>PL/Python</application>'s regression tests to pass
      with Python 3.10 (Honza Horak)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3779ac62d] 2021-07-24 13:41:17 -0400
Branch: REL_14_STABLE [89ad14cd7] 2021-07-24 13:41:17 -0400
Branch: REL_13_STABLE [c0a6f83de] 2021-07-24 13:41:17 -0400
Branch: REL_12_STABLE [4c8a14e8d] 2021-07-24 13:41:17 -0400
Branch: REL_11_STABLE [9329b9235] 2021-07-24 13:41:17 -0400
Branch: REL_10_STABLE [5a435289d] 2021-07-24 13:41:17 -0400
Branch: REL9_6_STABLE [7e09b504d] 2021-07-24 13:41:17 -0400
-->
     <para>
      Make <literal>printf("%s", NULL)</literal>
      print <literal>(null)</literal> instead of crashing (Tom Lane)
     </para>

     <para>
      This should improve server robustness in corner cases, and it syncs
      our <function>printf</function> implementation with common libraries.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [17707c059] 2021-06-30 11:48:53 +0900
Branch: REL_14_STABLE [607a3a43b] 2021-06-30 11:49:10 +0900
Branch: REL_13_STABLE [41edb2db1] 2021-06-30 11:49:16 +0900
Branch: REL_12_STABLE [b5ee867a7] 2021-06-30 11:49:20 +0900
Branch: REL_11_STABLE [93d3d0cf3] 2021-06-30 11:49:24 +0900
Branch: REL_10_STABLE [d8569db76] 2021-06-30 11:49:29 +0900
Branch: REL9_6_STABLE [68bad2333] 2021-06-30 11:49:36 +0900
-->
     <para>
      Fix incorrect log message when point-in-time recovery stops at
      a <command>ROLLBACK PREPARED</command> record (Simon Riggs)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_14_STABLE [0c83eb2e0] 2021-07-14 17:15:01 +0900
Branch: REL_13_STABLE [522624345] 2021-07-14 17:15:18 +0900
Branch: REL_12_STABLE [b242e1d23] 2021-07-14 17:15:26 +0900
Branch: REL_11_STABLE [85a8c3a4b] 2021-07-14 17:15:31 +0900
-->
     <para>
      Improve <command>ALTER TABLE</command>'s messages for
      wrong-relation-kind errors (Kyotaro Horiguchi)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [0e1275fb0] 2021-07-28 01:20:16 +0900
Branch: REL_14_STABLE [fd90f6ba7] 2021-07-28 01:21:35 +0900
Branch: REL_13_STABLE [92913fc29] 2021-07-28 01:21:52 +0900
Branch: REL_12_STABLE [de87c481f] 2021-07-28 01:24:24 +0900
Branch: REL_11_STABLE [42e6b5ccb] 2021-07-28 01:24:51 +0900
Branch: REL_10_STABLE [a84f95ffd] 2021-07-28 01:25:53 +0900
Branch: REL9_6_STABLE [78c21d79d] 2021-07-28 01:26:15 +0900
-->
     <para>
      Clarify error messages referring to <quote>non-negative</quote>
      values (Bharath Rupireddy)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d0a02bdb8] 2021-07-09 12:38:55 -0400
Branch: REL_14_STABLE [5620ec833] 2021-07-09 12:38:55 -0400
Branch: REL_13_STABLE [55cccdfdf] 2021-07-09 12:38:55 -0400
Branch: REL_12_STABLE [a5377e7f7] 2021-07-09 12:38:55 -0400
Branch: REL_11_STABLE [b69e8ad6c] 2021-07-09 12:38:55 -0400
Branch: REL_10_STABLE [7e0b53ad6] 2021-07-09 12:38:55 -0400
Branch: REL9_6_STABLE [cd5d3aefa] 2021-07-09 12:38:55 -0400
Branch: master [31e8cfac5] 2021-07-09 14:15:41 -0400
Branch: REL_14_STABLE [7f2eca6f9] 2021-07-09 14:15:41 -0400
Branch: REL_13_STABLE [cbcf5ffb1] 2021-07-09 14:15:41 -0400
Branch: REL_12_STABLE [83a8bf24e] 2021-07-09 14:15:41 -0400
Branch: REL_11_STABLE [29a4fbd46] 2021-07-09 14:15:41 -0400
Branch: REL_10_STABLE [911488b42] 2021-07-09 14:15:41 -0400
Branch: REL9_6_STABLE [8c9c20899] 2021-07-09 14:15:41 -0400
Branch: master [53c38a086] 2021-07-09 16:59:07 -0400
Branch: REL_14_STABLE [9ffad7ae7] 2021-07-09 16:59:07 -0400
Branch: REL_13_STABLE [32d0bdbfc] 2021-07-09 16:59:07 -0400
Branch: REL_12_STABLE [e82cde74d] 2021-07-09 16:59:08 -0400
Branch: REL_11_STABLE [2c28c689f] 2021-07-09 16:59:08 -0400
Branch: REL_10_STABLE [56533fce7] 2021-07-09 16:59:08 -0400
Branch: REL9_6_STABLE [3c612d9f6] 2021-07-09 16:59:08 -0400
Branch: master [9f6be2e79] 2021-07-10 13:19:30 -0400
Branch: REL_14_STABLE [ebc346e5b] 2021-07-10 13:19:31 -0400
Branch: REL_13_STABLE [9fca23c1d] 2021-07-10 13:19:31 -0400
Branch: REL_12_STABLE [03fc042eb] 2021-07-10 13:19:31 -0400
Branch: REL_11_STABLE [946f62f2f] 2021-07-10 13:19:31 -0400
-->
     <para>
      Fix <application>configure</application> to work with OpenLDAP 2.5,
      which no longer has a separate <filename>libldap_r</filename>
      library (Adrian Ho, Tom Lane)
     </para>

     <para>
      If there is no <filename>libldap_r</filename> library, we now
      silently assume that <filename>libldap</filename> is thread-safe.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [b8c4261e5] 2021-07-01 15:12:21 -0400
Branch: REL_14_STABLE [100e9ae53] 2021-07-01 15:15:09 -0400
Branch: REL_13_STABLE [bd0be7f7a] 2021-07-01 14:31:10 -0400
Branch: REL_12_STABLE [c71471c96] 2021-07-01 14:51:54 -0400
Branch: REL_11_STABLE [a7e3a390e] 2021-07-01 14:52:40 -0400
Branch: REL_10_STABLE [b796435be] 2021-07-01 15:07:20 -0400
Branch: REL9_6_STABLE [cbd5d7c85] 2021-07-01 15:11:53 -0400
Branch: master [7355c241e] 2021-07-01 15:47:46 -0400
Branch: REL_14_STABLE [1da2ea0cc] 2021-07-01 15:47:47 -0400
Branch: REL_13_STABLE [8d2be1402] 2021-07-01 15:40:42 -0400
Branch: REL_12_STABLE [383c29d1e] 2021-07-01 15:43:31 -0400
Branch: REL_11_STABLE [418041748] 2021-07-01 15:43:53 -0400
Branch: REL_10_STABLE [177531ee0] 2021-07-01 15:44:06 -0400
Branch: REL9_6_STABLE [1f7ea06d7] 2021-07-01 15:44:22 -0400
-->
     <para>
      Add new make targets <literal>world-bin</literal>
      and <literal>install-world-bin</literal> (Andrew Dunstan)
     </para>

     <para>
      These are the same as <literal>world</literal>
      and <literal>install-world</literal> respectively, except that they
      do not build or install the documentation.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [a0fc81326] 2021-07-01 09:02:46 -0400
Branch: REL_14_STABLE [c4774ce33] 2021-07-01 08:46:21 -0400
Branch: REL_13_STABLE [a8b564b0c] 2021-07-01 08:46:38 -0400
Branch: REL_12_STABLE [a40f8ea0f] 2021-07-01 08:47:04 -0400
Branch: REL_11_STABLE [58ac8300b] 2021-07-01 08:47:21 -0400
Branch: REL_10_STABLE [16ed3ddbb] 2021-07-01 08:48:24 -0400
Branch: REL9_6_STABLE [d173a4699] 2021-07-01 09:01:36 -0400
-->
     <para>
      Fix make rule for TAP tests (<literal>prove_installcheck</literal>)
      to work in PGXS usage (Andrew Dunstan)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master Release: REL_14_BR [9b4e4cfe6] 2021-06-25 11:28:20 +1200
Branch: REL_13_STABLE [d9c05a9ec] 2021-06-25 11:29:00 +1200
Branch: REL_12_STABLE [47d22649e] 2021-06-25 11:29:20 +1200
Branch: REL_11_STABLE [6ada4fd06] 2021-06-25 11:29:47 +1200
-->
     <para>
      Adjust JIT code to prepare for forthcoming LLVM API change
      (Thomas Munro, Andres Freund)
     </para>

     <para>
      LLVM 13 has made an incompatible API change that will cause crashing
      of our previous JIT compiler.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [126cdaf47] 2021-06-23 14:01:32 -0400
Branch: REL_13_STABLE [13f365568] 2021-06-23 14:01:32 -0400
Branch: REL_12_STABLE [7eaf65451] 2021-06-23 14:01:32 -0400
Branch: REL_11_STABLE [361acef7e] 2021-06-23 14:01:32 -0400
Branch: REL_10_STABLE [d3a845d1f] 2021-06-23 14:01:32 -0400
Branch: REL9_6_STABLE [006a829b2] 2021-06-23 14:01:33 -0400
-->
     <para>
      Avoid assuming that strings returned by GSSAPI libraries are
      null-terminated (Tom Lane)
     </para>

     <para>
      The GSSAPI spec provides for a string pointer and length.  It seems
      that in practice the next byte after the string is usually zero,
      so that our previous coding didn't actually fail; but we do have
      a report of AddressSanitizer complaints.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master Release: REL_14_BR [025110663] 2021-05-27 20:11:00 +0900
Branch: REL_13_STABLE [ab81d004e] 2021-05-27 20:11:21 +0900
Branch: REL_12_STABLE [a75268f1c] 2021-05-27 20:11:24 +0900
Branch: REL_11_STABLE [cf2e09544] 2021-05-27 20:11:29 +0900
Branch: REL_10_STABLE [8f507dbc6] 2021-05-27 20:11:33 +0900
Branch: REL9_6_STABLE [7a4f2e158] 2021-05-27 20:11:38 +0900
Branch: master Release: REL_14_BR [7ca37fb04] 2020-12-30 12:56:06 -0500
Branch: REL_13_STABLE [e2f21ff60] 2021-06-01 09:27:25 +0900
Branch: REL_12_STABLE [02037af3f] 2021-06-01 09:27:31 +0900
Branch: REL_13_STABLE [949e32ee5] 2021-06-08 13:40:03 +0900
Branch: REL_12_STABLE [b7684bd10] 2021-06-08 13:40:10 +0900
-->
     <para>
      Enable building with GSSAPI on MSVC (Michael Paquier)
     </para>

     <para>
      Fix various incompatibilities with modern Kerberos builds.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master Release: REL_14_BR [fb424ae85] 2021-05-28 09:30:16 -0400
Branch: REL_13_STABLE [c828a7246] 2021-05-28 09:31:50 -0400
Branch: REL_12_STABLE [ae3ef8569] 2021-05-28 09:32:09 -0400
Branch: REL_11_STABLE [3f70d7e44] 2021-05-28 09:32:24 -0400
Branch: REL_10_STABLE [a8c1062a1] 2021-05-28 09:32:31 -0400
Branch: REL9_6_STABLE [abbd70022] 2021-05-28 09:32:46 -0400
Branch: master Release: REL_14_BR [d69fcb9ca] 2021-05-28 09:35:11 -0400
Branch: REL_13_STABLE [bb18bc224] 2021-05-28 09:36:42 -0400
Branch: REL_12_STABLE [40a05cf24] 2021-05-28 09:35:42 -0400
Branch: REL_11_STABLE [a44a2b9ac] 2021-05-28 09:35:49 -0400
Branch: REL_10_STABLE [d5d89629c] 2021-05-28 09:35:55 -0400
Branch: REL9_6_STABLE [34a65fc63] 2021-05-28 09:36:10 -0400
-->
     <para>
      In MSVC builds, include <option>--with-pgport</option> in the set of
      configure options reported by <application>pg_config</application>,
      if it had been specified (Andrew Dunstan)
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-3">
  <title>Release 13.3</title>

  <formalpara>
  <title>Release date:</title>
  <para>2021-05-13</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.2.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.3</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, if you are upgrading from a version earlier than 13.2,
    see <xref linkend="release-13-2"/>.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f02b9085a] 2021-05-10 10:44:38 -0400
Branch: REL_13_STABLE [467395bfd] 2021-05-10 10:44:38 -0400
Branch: REL_12_STABLE [3b0f6a7ae] 2021-05-10 10:44:38 -0400
Branch: REL_11_STABLE [06bfbe854] 2021-05-10 10:44:38 -0400
Branch: REL_10_STABLE [2fb809d3e] 2021-05-10 10:44:38 -0400
Branch: REL9_6_STABLE [0c1caa48d] 2021-05-10 10:44:38 -0400
-->
     <para>
      Prevent integer overflows in array subscripting calculations
      (Tom Lane)
     </para>

     <para>
      The array code previously did not complain about cases where an
      array's lower bound plus length overflows an integer.  This resulted
      in later entries in the array becoming inaccessible (since their
      subscripts could not be written as integers), but more importantly
      it confused subsequent assignment operations.  This could lead to
      memory overwrites, with ensuing crashes or unwanted data
      modifications.
      (CVE-2021-32027)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [049e1e2ed] 2021-05-10 11:02:29 -0400
Branch: REL_13_STABLE [4a8656a7e] 2021-05-10 11:02:29 -0400
Branch: REL_12_STABLE [a5fa3e067] 2021-05-10 11:02:29 -0400
Branch: REL_11_STABLE [b7d1f32ff] 2021-05-10 11:02:29 -0400
Branch: REL_10_STABLE [52a441362] 2021-05-10 11:02:30 -0400
Branch: REL9_6_STABLE [0fcb8e2e0] 2021-05-10 11:02:30 -0400
-->
     <para>
      Fix mishandling of <quote>junk</quote> columns in <literal>INSERT
      ... ON CONFLICT ... UPDATE</literal> target lists (Tom Lane)
     </para>

     <para>
      If the <literal>UPDATE</literal> list contains any multi-column
      sub-selects (which give rise to junk columns in addition to the
      results proper), the <literal>UPDATE</literal> path would end up
      storing tuples that include the values of the extra junk columns.
      That's fairly harmless in the short run, but if new columns are
      added to the table then the values would become accessible, possibly
      leading to malfunctions if they don't match the datatypes of the
      added columns.
     </para>

     <para>
      In addition, in versions supporting cross-partition updates,
      a cross-partition update triggered by such a case had the reverse
      problem: the junk columns were removed from the target list,
      typically causing an immediate crash due to malfunction of the
      multi-column sub-select mechanism.
      (CVE-2021-32028)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_13_STABLE [a71cfc56b] 2021-04-22 11:46:41 -0400
Branch: REL_12_STABLE [3fb93103a] 2021-04-22 11:46:41 -0400
Branch: REL_11_STABLE [27835b547] 2021-04-22 11:46:41 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d479d0028] 2021-04-22 17:30:55 -0400
Branch: REL_13_STABLE [2602ee468] 2021-04-22 17:30:42 -0400
Branch: REL_12_STABLE [05ce4bf8b] 2021-04-22 17:30:42 -0400
-->
     <para>
      Fix possibly-incorrect computation of <command>UPDATE
      ... RETURNING</command> outputs for joined cross-partition updates
      (Amit Langote, Etsuro Fujita)
     </para>

     <para>
      If an <command>UPDATE</command> for a partitioned table caused a row
      to be moved to another partition with a physically different row
      type (for example, one with a different set of dropped columns),
      computation of <literal>RETURNING</literal> results for that row
      could produce errors or wrong answers.  No error is observed unless
      the <command>UPDATE</command> involves other tables being joined to
      the target table.
      (CVE-2021-32029)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [6f70d7ca1] 2021-05-05 12:21:50 -0400
Branch: REL_13_STABLE [923c13520] 2021-05-05 12:14:21 -0400
Branch: REL_12_STABLE [abce26c9e] 2021-05-05 12:14:21 -0400
Branch: REL_11_STABLE [a25b98d2c] 2021-05-05 12:14:21 -0400
-->
     <para>
      Fix adjustment of constraint deferrability properties in
      partitioned tables (&Aacute;lvaro Herrera)
     </para>

     <para>
      When applied to a foreign-key constraint of a partitioned table,
      <command>ALTER TABLE ... ALTER CONSTRAINT</command> failed to
      adjust the <literal>DEFERRABLE</literal> and/or
      <literal>INITIALLY DEFERRED</literal> markings of the constraints
      and triggers of leaf partitions.  This led to unexpected behavior of
      such constraints.  After updating to this version, any misbehaving
      partitioned tables can be fixed by executing a
      new <command>ALTER</command> command to set the desired properties.
     </para>

     <para>
      This change also disallows applying such an <command>ALTER</command>
      directly to the constraints of leaf partitions.  The only supported
      case is for the whole partitioning hierarchy to have identical
      constraint properties, so such <command>ALTER</command>s must be
      applied at the partition root.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [a970edbed] 2021-05-04 12:09:08 +0200
Branch: REL_13_STABLE [64190d65f] 2021-05-04 12:10:22 +0200
Branch: REL_12_STABLE [13ff139a2] 2021-05-04 12:10:51 +0200
-->
     <para>
      When attaching a child table with <command>ALTER TABLE
      ... INHERIT</command>, insist that any generated columns in the
      parent be generated the same way in the child (Peter Eisentraut)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f52c5d674] 2021-03-12 11:08:42 -0500
Branch: REL_13_STABLE [8a2297776] 2021-03-12 11:08:42 -0500
Branch: REL_12_STABLE [e7f7950f6] 2021-03-12 11:08:42 -0500
Branch: REL_11_STABLE [6c34f186c] 2021-03-12 11:08:42 -0500
Branch: REL_10_STABLE [e5794cd59] 2021-03-12 11:08:42 -0500
-->
     <para>
      Forbid marking an identity column as nullable (Vik Fearing)
     </para>

     <para>
      <literal>GENERATED ... AS IDENTITY</literal> implies <literal>NOT
      NULL</literal>, so don't allow it to be combined with an
      explicit <literal>NULL</literal> specification.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [69d5ca484] 2021-04-13 15:10:18 -0400
Branch: REL_13_STABLE [c39aa1e87] 2021-04-13 15:10:18 -0400
Branch: REL_12_STABLE [a7fcb6285] 2021-04-13 15:10:18 -0400
Branch: REL_11_STABLE [c7f0275fb] 2021-04-13 15:10:18 -0400
Branch: REL_10_STABLE [46b6635b7] 2021-04-13 15:10:18 -0400
Branch: REL9_6_STABLE [041f4efd2] 2021-04-13 15:10:18 -0400
-->
     <para>
      Allow <literal>ALTER ROLE/DATABASE ... SET</literal> to set
      the <varname>role</varname>, <varname>session_authorization</varname>,
      and <varname>temp_buffers</varname> parameters (Tom Lane)
     </para>

     <para>
      Previously, over-eager validity checks might reject these commands,
      even if the values would have worked when used later.  This created
      a command ordering hazard for dump/reload and upgrade scenarios.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [bd1208098] 2021-02-10 13:06:48 +0900
Branch: REL_13_STABLE [849383138] 2021-02-10 13:09:09 +0900
Branch: REL_12_STABLE [85edb1f26] 2021-02-10 13:09:12 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [4f4726005] 2021-02-10 16:59:04 +0900
Branch: REL_13_STABLE [c6cd20d91] 2021-02-10 16:59:33 +0900
Branch: REL_12_STABLE [5b2945ec0] 2021-02-10 16:59:43 +0900
-->
     <para>
      Ensure that <command>REINDEX CONCURRENTLY</command> preserves any
      statistics target that's been set for the index (Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [8a55cb5ba] 2021-02-19 21:57:52 +0900
Branch: REL_13_STABLE [422012c98] 2021-02-19 21:58:43 +0900
Branch: REL_12_STABLE [fadcc4e81] 2021-02-19 21:59:26 +0900
-->
     <para>
      Fix <command>COMMIT AND CHAIN</command> to work correctly when the
      current transaction has live savepoints (Fujii Masao)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [80ca8464f] 2021-02-25 20:47:32 -0500
Branch: REL_13_STABLE [49076fd3b] 2021-02-25 20:47:32 -0500
-->
     <para>
      Fix list-manipulation bug in <literal>WITH RECURSIVE</literal>
      processing (Michael Paquier, Tom Lane)
     </para>

     <para>
      Sufficiently deep nesting of <literal>WITH</literal> constructs
      (at least seven levels) triggered core dumps or incorrect complaints
      of faulty <literal>WITH</literal> nesting.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c402b02b9] 2021-04-12 14:37:49 -0400
Branch: REL_13_STABLE [8a7bd1e6c] 2021-04-12 14:37:22 -0400
Branch: REL_12_STABLE [27011bcff] 2021-04-12 14:37:22 -0400
Branch: REL_11_STABLE [fb2cca828] 2021-04-12 14:37:22 -0400
Branch: REL_10_STABLE [4b0aecee8] 2021-04-12 14:37:22 -0400
Branch: REL9_6_STABLE [a6158a4d9] 2021-04-12 14:37:22 -0400
-->
     <para>
      Fix bug with coercing the result of a <literal>COLLATE</literal>
      expression to a non-collatable type (Tom Lane)
     </para>

     <para>
      This led to a parse tree in which the <literal>COLLATE</literal>
      appears to be applied to a non-collatable value.  While that
      normally has no real impact (since <literal>COLLATE</literal> has no
      effect at runtime), it was possible to construct views that would be
      rejected during dump/reload.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [25936fd46] 2021-02-27 18:09:15 -0300
Branch: REL_13_STABLE [2688852a4] 2021-02-27 18:09:15 -0300
Branch: REL_12_STABLE [262eb990c] 2021-02-27 18:09:15 -0300
-->
     <para>
      Fix use-after-free bug in saving tuples for <literal>AFTER</literal>
      triggers (Amit Langote)
     </para>

     <para>
      This could cause crashes in some situations.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2efcd502e] 2021-04-30 14:10:26 -0400
Branch: REL_13_STABLE [4d225ba0e] 2021-04-30 14:10:26 -0400
Branch: REL_12_STABLE [89768ee69] 2021-04-30 14:10:26 -0400
Branch: REL_11_STABLE [ebc2ff076] 2021-04-30 14:10:26 -0400
Branch: REL_10_STABLE [0627f3630] 2021-04-30 14:10:26 -0400
Branch: REL9_6_STABLE [73bad52a9] 2021-04-30 14:10:26 -0400
-->
     <para>
      Disallow calling window functions and procedures via
      the <quote>fast path</quote> wire protocol message (Tom Lane)
     </para>

     <para>
      Only plain functions are supported here.  While trying to call
      an aggregate function failed already, calling a window function
      would crash, and calling a procedure would work only if the
      procedure did no transaction control.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [f7aab36d6] 2021-04-28 11:17:58 +0900
Branch: REL_13_STABLE [f3c453787] 2021-04-28 11:18:17 +0900
Branch: REL_12_STABLE [7e76cb1d8] 2021-04-28 11:18:20 +0900
Branch: REL_11_STABLE [5b717e13c] 2021-04-28 11:18:24 +0900
Branch: REL_10_STABLE [90c9bad30] 2021-04-28 11:18:28 +0900
Branch: REL9_6_STABLE [6e41ff056] 2021-04-28 11:18:33 +0900
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [f93f0b5b2] 2021-04-28 11:58:08 +0900
Branch: REL_13_STABLE [a928297bc] 2021-04-28 11:58:43 +0900
Branch: REL_12_STABLE [85a3e0be1] 2021-04-28 11:58:46 +0900
Branch: REL_11_STABLE [669f73666] 2021-04-28 11:58:50 +0900
Branch: REL_10_STABLE [b797918d2] 2021-04-28 11:58:55 +0900
Branch: REL9_6_STABLE [0d05a3a1d] 2021-04-28 11:59:00 +0900
-->
     <para>
      Extend <function>pg_identify_object_as_address()</function>
      to support event triggers (Joel Jacobson)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [7a3972597] 2021-04-12 11:30:50 +0900
Branch: REL_13_STABLE [be79debd9] 2021-04-12 11:31:26 +0900
Branch: REL_12_STABLE [82dd5706e] 2021-04-12 11:31:30 +0900
Branch: REL_11_STABLE [5656f2c3d] 2021-04-12 11:31:35 +0900
Branch: REL_10_STABLE [1cc110f68] 2021-04-12 11:31:40 +0900
Branch: REL9_6_STABLE [6540322fa] 2021-04-12 11:31:46 +0900
-->
     <para>
      Fix <function>to_char()</function>'s handling of Roman-numeral month
      format codes with negative intervals (Julien Rouhaud)
     </para>

     <para>
      Previously, such cases would usually cause a crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5c06abb9b] 2021-03-08 18:21:51 -0500
Branch: REL_13_STABLE [fe2b5386b] 2021-03-08 18:21:51 -0500
Branch: REL_12_STABLE [8fff8a874] 2021-03-08 18:21:51 -0500
Branch: REL_11_STABLE [ea42ccbce] 2021-03-08 18:21:51 -0500
Branch: REL_10_STABLE [37228ecde] 2021-03-08 18:21:51 -0500
-->
     <para>
      Check that the argument
      of <function>pg_import_system_collations()</function> is a valid
      schema OID (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b5a66e735] 2021-02-18 22:38:55 -0500
Branch: REL_13_STABLE [bf9d3a5f8] 2021-02-18 22:38:55 -0500
Branch: REL_12_STABLE [e7cddb5f2] 2021-02-18 22:38:55 -0500
Branch: REL_11_STABLE [6e6fecf49] 2021-02-18 22:38:55 -0500
Branch: REL_10_STABLE [b06450979] 2021-02-18 22:38:55 -0500
Branch: REL9_6_STABLE [ab208421e] 2021-02-18 22:38:55 -0500
-->
     <para>
      Fix use of uninitialized value while parsing an
      <literal>\{<replaceable>m</replaceable>,<replaceable>n</replaceable>\}</literal>
      quantifier in a BRE-mode regular expression (Tom Lane)
     </para>

     <para>
      This error could cause the quantifier to act non-greedy, that is
      behave like an
      <literal>{<replaceable>m</replaceable>,<replaceable>n</replaceable>}?</literal>
      quantifier would do in full regular expressions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [375398244] 2021-04-20 11:32:02 -0400
Branch: REL_13_STABLE [7bfba4f19] 2021-04-20 11:32:02 -0400
-->
     <para>
      Fix <quote>could not find pathkey item to sort</quote> planner
      errors in some situations where the sort key involves an aggregate
      or window function (James Coleman, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [33e52ad9a] 2021-03-26 22:34:58 +0100
Branch: REL_13_STABLE [67251c82a] 2021-03-26 22:37:45 +0100
Branch: REL_12_STABLE [88acb0135] 2021-03-26 22:40:00 +0100
Branch: REL_11_STABLE [2a307df1b] 2021-03-26 22:44:01 +0100
Branch: REL_10_STABLE [e5eb40eed] 2021-03-26 22:46:15 +0100
-->
     <para>
      Don't ignore system columns when estimating the number of groups
      using extended statistics (Tomas Vondra)
     </para>

     <para>
      This led to strange estimates for queries such as <literal>SELECT
      ... GROUP BY a, b, ctid</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ae4867ec7] 2021-02-12 16:26:47 -0500
Branch: REL_13_STABLE [3a02d68a9] 2021-02-12 16:26:47 -0500
Branch: REL_12_STABLE [0347470b3] 2021-02-12 16:26:47 -0500
Branch: REL_11_STABLE [a28df6fa3] 2021-02-12 16:26:47 -0500
Branch: REL_10_STABLE [374f1cefe] 2021-02-12 16:26:47 -0500
Branch: REL9_6_STABLE [f4d781dae] 2021-02-12 16:26:47 -0500
-->
     <para>
      Avoid divide-by-zero when estimating selectivity of a regular
      expression with a very long fixed prefix (Tom Lane)
     </para>

     <para>
      This typically led to a <literal>NaN</literal> selectivity value,
      causing assertion failures or strange planner behavior.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [23607a815] 2021-04-07 15:58:36 +0200
Branch: REL_13_STABLE [1aad1d181] 2021-04-07 15:59:30 +0200
Branch: REL_12_STABLE [847612fda] 2021-04-07 16:01:27 +0200
Branch: REL_11_STABLE [7d3a53461] 2021-04-07 16:02:51 +0200
Branch: REL_10_STABLE [e4f251be7] 2021-04-07 16:04:05 +0200
Branch: REL9_6_STABLE [df97ee6ea] 2021-04-07 16:05:21 +0200
-->
     <para>
      Fix access-off-the-end-of-the-table error in BRIN index bitmap scans
      (Tomas Vondra)
     </para>

     <para>
      If the page range size used by a BRIN index isn't a power of two,
      there were corner cases in which a bitmap scan could try to fetch
      pages past the actual end of the table, leading to <quote>could not
      open file</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [38bb3aef3] 2021-02-16 12:07:14 -0500
Branch: REL_13_STABLE [0d779d22a] 2021-02-16 12:07:14 -0500
-->
     <para>
      Fix potentially wrong answers from GIN <type>tsvector</type> index
      searches, when there are many matching tuples (Tom Lane)
     </para>

     <para>
      If the number of index matches became large enough to make the
      bitmap holding them become lossy (a threshold that depends
      on <varname>work_mem</varname>), the code could get confused about
      whether rechecks are required, allowing rows to be returned that
      don't actually match the query.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [909b449e0] 2021-03-22 14:02:26 +0900
Branch: REL_13_STABLE [78c24e97d] 2021-03-22 14:02:36 +0900
-->
     <para>
      Fix concurrency issues with WAL segment recycling on Windows
      (Michael Paquier)
     </para>

     <para>
      This reverts a change that caused intermittent <quote>could not
      rename file ...: Permission denied</quote> log messages.  While
      there were not serious consequences, the log spam was annoying.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [595b9cba2] 2021-03-22 08:30:53 +0900
Branch: REL_13_STABLE [6e5ce888a] 2021-03-22 08:31:01 +0900
Branch: REL_12_STABLE [4b1dd9b1e] 2021-03-22 08:31:05 +0900
Branch: REL_11_STABLE [f1d550f18] 2021-03-22 08:31:09 +0900
Branch: REL_10_STABLE [1ec7162a8] 2021-03-22 08:31:14 +0900
-->
     <para>
      Avoid incorrect timeline change while recovering uncommitted
      two-phase transactions from WAL (Soumyadeep Chakraborty, Jimmy Yih,
      Kevin Yeap)
     </para>

     <para>
      This error could lead to subsequent WAL records being written under
      the wrong timeline ID, leading to consistency problems, or even
      complete failure to be able to restart the server, later on.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [ad8b67492] 2021-04-06 02:25:37 +0900
Branch: REL_13_STABLE [e7bcfd717] 2021-04-06 02:27:11 +0900
Branch: REL_12_STABLE [dd5b7e486] 2021-04-06 02:27:22 +0900
Branch: REL_11_STABLE [b59d3abaf] 2021-04-06 02:27:30 +0900
Branch: REL_10_STABLE [b9cf9d7d3] 2021-04-06 02:27:39 +0900
Branch: REL9_6_STABLE [e3bf96216] 2021-04-06 02:27:48 +0900
-->
     <para>
      Ensure that locks are released while shutting down a standby
      server's startup process (Fujii Masao)
     </para>

     <para>
      When a standby server is shut down while still in recovery, some
      locks might be left held.  This causes assertion failures in debug
      builds; it's unclear whether any serious consequence could occur
      in production builds.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [4e8c0f1a0] 2021-05-07 11:46:37 -0400
Branch: REL_13_STABLE [ef70b6f8e] 2021-05-07 11:46:37 -0400
Branch: REL_12_STABLE [cfebc7080] 2021-05-07 11:46:37 -0400
Branch: REL_11_STABLE [b40865ebd] 2021-05-07 11:46:37 -0400
Branch: REL_10_STABLE [1803c7626] 2021-05-07 11:46:37 -0400
-->
     <para>
      Fix crash when a logical replication worker does <command>ALTER
      SUBSCRIPTION REFRESH</command> (Peter Smith)
     </para>

     <para>
      The core code won't do this, but a replica trigger could.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [f900a79ec] 2021-02-15 16:04:59 +1300
Branch: REL_13_STABLE [6c23e5ae9] 2021-02-15 16:05:42 +1300
Branch: REL_12_STABLE [a27f3a7f4] 2021-02-15 16:06:18 +1300
Branch: REL_11_STABLE [1fefe8879] 2021-02-15 16:06:25 +1300
Branch: REL_10_STABLE [800131df7] 2021-02-15 16:08:24 +1300
Branch: REL9_6_STABLE [09a3b19e3] 2021-02-15 16:09:14 +1300
-->
     <para>
      Ensure we default to <varname>wal_sync_method</varname>
      = <literal>fdatasync</literal> on recent FreeBSD (Thomas Munro)
     </para>

     <para>
      FreeBSD 13 supports <literal>open_datasync</literal>, which would
      normally become the default choice.  However, it's unclear whether
      that is actually an improvement for Postgres, so preserve the
      existing default for now.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [9f3665fbf] 2021-03-10 16:27:01 -0800
Branch: REL_13_STABLE [9663d1244] 2021-03-10 16:26:58 -0800
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [5f8727f5a] 2021-03-10 17:07:57 -0800
Branch: REL_13_STABLE [1fc5a5738] 2021-03-10 17:07:55 -0800
-->
     <para>
      Disable the <varname>vacuum_cleanup_index_scale_factor</varname>
      parameter and storage option (Peter Geoghegan)
     </para>

     <para>
      The notion of tracking <quote>stale</quote> index statistics proved
      to interact badly with
      the <varname>autovacuum_vacuum_insert_threshold</varname> parameter,
      resulting in unnecessary full-index scans and consequent degradation
      of autovacuum performance.  The latter mechanism seems superior, so
      remove the stale-statistics logic.  The control parameter for that,
      <varname>vacuum_cleanup_index_scale_factor</varname>, will be
      removed entirely in v14.  In v13, it remains present to avoid
      breaking existing configuration files, but it no longer does
      anything.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [e798d095d] 2021-05-04 10:09:12 -0400
Branch: REL_13_STABLE [91a6b3862] 2021-05-04 10:09:11 -0400
Branch: REL_12_STABLE [72fabd4bf] 2021-05-04 10:09:11 -0400
-->
     <para>
      Pass the correct trigger OID to object post-alter hooks
      during <command>ALTER CONSTRAINT</command> (&Aacute;lvaro Herrera)
     </para>

     <para>
      When updating trigger properties during <command>ALTER
      CONSTRAINT</command>, the post-alter hook was told that we are
      updating a trigger, but the constraint's OID was passed instead of
      the trigger's.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [637668fb1] 2021-02-15 14:27:33 +1300
Branch: REL_13_STABLE [9fe40913c] 2021-02-15 14:20:42 +1300
Branch: REL_12_STABLE [840eda04e] 2021-02-15 14:20:52 +1300
Branch: REL_11_STABLE [acafdd9ed] 2021-02-15 14:21:01 +1300
Branch: REL_10_STABLE [4b426f77c] 2021-02-15 14:22:08 +1300
Branch: REL9_6_STABLE [8a07e5bd8] 2021-02-15 14:22:19 +1300
-->
     <para>
      Ensure we finish cleaning up when interrupted while detaching a DSM
      segment (Thomas Munro)
     </para>

     <para>
      This error could result in temporary files not being cleaned up
      promptly after a parallel query.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e835e89a0] 2021-03-20 12:47:21 -0400
Branch: REL_13_STABLE [4b41f6923] 2021-03-20 12:47:35 -0400
Branch: REL_12_STABLE [2f31414f4] 2021-03-20 12:47:42 -0400
Branch: REL_11_STABLE [8c830148d] 2021-03-20 12:47:48 -0400
Branch: REL_10_STABLE [ad6c19066] 2021-03-20 12:47:53 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9bacdf9f5] 2021-03-18 22:22:47 -0400
Branch: REL_13_STABLE [12354839e] 2021-03-18 22:21:58 -0400
Branch: REL_12_STABLE [4eca51d44] 2021-03-18 22:21:58 -0400
Branch: REL_11_STABLE [20f11ca0d] 2021-03-18 22:21:58 -0400
Branch: REL_10_STABLE [ba986b7bc] 2021-03-18 22:21:58 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [377b7a830] 2021-03-18 22:22:47 -0400
Branch: REL_13_STABLE [642b0b69b] 2021-03-18 22:09:41 -0400
Branch: REL_12_STABLE [fc552f868] 2021-03-18 22:09:41 -0400
Branch: REL_11_STABLE [26a3ae06d] 2021-03-18 22:09:41 -0400
Branch: REL_10_STABLE [5058e95a6] 2021-03-18 22:09:41 -0400
Branch: REL9_6_STABLE [7e2521770] 2021-03-18 22:09:41 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d303849b0] 2021-03-18 22:22:47 -0400
Branch: REL_13_STABLE [eba939551] 2021-03-18 21:44:43 -0400
Branch: REL_12_STABLE [92bc14a10] 2021-03-18 21:44:43 -0400
Branch: REL_11_STABLE [099d2914f] 2021-03-18 21:44:43 -0400
Branch: REL_10_STABLE [0b618ddf8] 2021-03-18 21:44:43 -0400
Branch: REL9_6_STABLE [09e961929] 2021-03-18 21:44:43 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [415ffdc22] 2021-03-18 22:22:47 -0400
Branch: REL_13_STABLE [ea3989f34] 2021-03-18 20:50:56 -0400
Branch: REL_12_STABLE [1452a0bb8] 2021-03-18 20:50:56 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [28644fac1] 2021-03-18 22:22:47 -0400
Branch: REL_13_STABLE [536836970] 2021-03-18 20:37:09 -0400
Branch: REL_12_STABLE [fbcc9fe33] 2021-03-18 20:37:09 -0400
Branch: REL_11_STABLE [967b693ea] 2021-03-18 20:37:09 -0400
Branch: REL_10_STABLE [2bed650c4] 2021-03-18 20:37:09 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4b12ab18c] 2021-03-16 16:03:06 -0400
Branch: REL_13_STABLE [4d072bf2a] 2021-03-16 16:02:49 -0400
Branch: REL_12_STABLE [6e3475556] 2021-03-16 16:02:49 -0400
Branch: REL_11_STABLE [a2764d87d] 2021-03-16 16:02:50 -0400
Branch: REL_10_STABLE [7ce7f2b79] 2021-03-16 16:02:50 -0400
-->
     <para>
      Fix assorted minor memory leaks in the server (Tom Lane, Andres Freund)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [614b7f18b] 2021-02-18 23:28:15 +0900
Branch: REL_13_STABLE [d4b667e93] 2021-02-18 23:28:58 +0900
-->
     <para>
      Fix uninitialized variable in walreceiver's statistics in shared
      memory (Fujii Masao)
     </para>

     <para>
      This error was harmless on most platforms, but could cause issues
      on platforms lacking atomic variables and/or spinlock support.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [b94409a02] 2021-05-03 12:18:27 +0200
Branch: REL_13_STABLE [e48ce7ef0] 2021-05-03 21:01:09 +0200
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [fa8fbadb9] 2021-05-10 11:40:03 +0200
Branch: REL_13_STABLE [0d204a4b0] 2021-05-10 13:56:21 +0200
-->
     <para>
      Reduce the overhead of dtrace probes for LWLock operations, when
      dtrace support is compiled in but not active (Peter Eisentraut)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c2db458c1] 2021-04-13 13:37:07 -0400
Branch: REL_13_STABLE [97b7ad468] 2021-04-13 13:37:07 -0400
Branch: REL_12_STABLE [6530df6c2] 2021-04-13 13:37:07 -0400
Branch: REL_11_STABLE [22f2a98cf] 2021-04-13 13:37:07 -0400
-->
     <para>
      Fix failure when a PL/pgSQL <command>DO</command> block makes use of
      both composite-type variables and transaction control (Tom Lane)
     </para>

     <para>
      Previously, such cases led to errors about leaked tuple descriptors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [51c54bb60] 2021-03-11 14:43:45 -0500
Branch: REL_13_STABLE [3580b4a0c] 2021-03-11 14:43:45 -0500
Branch: REL_12_STABLE [56defbdd0] 2021-03-11 14:43:45 -0500
Branch: REL_11_STABLE [d3a557894] 2021-03-11 14:43:45 -0500
Branch: REL_10_STABLE [d2be6cdc5] 2021-03-11 14:43:45 -0500
Branch: REL9_6_STABLE [a98e53e10] 2021-03-11 14:43:45 -0500
-->
     <para>
      Prevent infinite loop in <application>libpq</application>
      if a ParameterDescription message with a corrupt length is received
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [75dbfe4ca] 2021-03-02 15:39:34 -0300
Branch: REL_13_STABLE [b52fd1e7c] 2021-03-02 15:39:34 -0300
Branch: REL_12_STABLE [f92776791] 2021-03-02 15:39:34 -0300
Branch: REL_11_STABLE [ae1c1d84e] 2021-03-02 15:39:34 -0300
Branch: REL_10_STABLE [926139dd0] 2021-03-02 15:39:34 -0300
-->
     <para>
      When <application>initdb</application> prints instructions about how
      to start the server, make the path shown
      for <application>pg_ctl</application> use backslash separators on
      Windows (Nitin Jadhav)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ea8013854] 2021-03-23 14:27:50 -0400
Branch: REL_13_STABLE [c6eac71a8] 2021-03-23 14:27:50 -0400
Branch: REL_12_STABLE [beac4bd65] 2021-03-23 14:27:50 -0400
Branch: REL_11_STABLE [d75edab42] 2021-03-23 14:27:50 -0400
Branch: REL_10_STABLE [d5a905ed5] 2021-03-23 14:27:50 -0400
Branch: REL9_6_STABLE [4f670c64e] 2021-03-23 14:27:50 -0400
-->
     <para>
      Fix <application>psql</application> to restore the previous behavior
      of <literal>\connect
      service=<replaceable>something</replaceable></literal> (Tom Lane)
     </para>

     <para>
      A previous bug fix caused environment variables (such
      as <varname>PGPORT</varname>) to override entries in the service
      file in this context.  Restore the previous behavior, in which the
      priority is the other way around.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [fe06819f1] 2021-02-19 22:01:25 +0900
Branch: REL_13_STABLE [be7485a1e] 2021-02-19 22:02:19 +0900
Branch: REL_12_STABLE [67b3ee292] 2021-02-19 22:02:44 +0900
-->
     <para>
      Fix <application>psql</application>'s <literal>ON_ERROR_ROLLBACK</literal>
      feature to handle <literal>COMMIT AND CHAIN</literal> commands
      correctly (Arthur Nascimento)
     </para>

     <para>
      Previously, this case failed with <quote>savepoint
      "pg_psql_temporary_savepoint" does not exist</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [8d645a116] 2021-03-29 18:34:39 -0300
Branch: REL_13_STABLE [f50dc2c72] 2021-03-29 18:34:39 -0300
-->
     <para>
      In <application>psql</application>, avoid repeated <quote>could not
      print result table</quote> failures after the first such error
      (&Aacute;lvaro Herrera)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [48d67fd89] 2021-03-12 12:20:15 -0500
Branch: REL_13_STABLE [6ed059933] 2021-03-12 12:20:15 -0500
Branch: REL_12_STABLE [60e5c2b14] 2021-03-12 12:20:15 -0500
Branch: REL_11_STABLE [33aa7d13d] 2021-03-12 12:20:15 -0500
Branch: REL_10_STABLE [8915e7906] 2021-03-12 12:20:15 -0500
Branch: REL9_6_STABLE [a42c4438b] 2021-03-12 12:20:15 -0500
-->
     <para>
      Fix race condition in detection of file modification by
      <application>psql</application>'s <literal>\e</literal> and related
      commands (Laurenz Albe)
     </para>

     <para>
      A very fast typist could fool the code's file-timestamp-based
      detection of whether the temporary edit file was changed.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [feb270d10] 2021-05-04 14:18:16 +0200
Branch: REL_13_STABLE [a6a3a274a] 2021-05-04 14:18:23 +0200
Branch: REL_12_STABLE [bdaa0d2d7] 2021-05-04 14:18:33 +0200
-->
     <para>
      Fix <application>pg_dump</application>'s dumping of
      generated columns in partitioned tables (Peter Eisentraut)
     </para>

     <para>
      A fix introduced in the previous minor release should not be applied
      to partitioned tables, only traditionally-inherited tables.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ec03f2df1] 2021-04-01 13:34:16 -0400
Branch: REL_13_STABLE [35421a470] 2021-04-01 13:34:16 -0400
Branch: REL_12_STABLE [84c5e0dd2] 2021-04-01 13:34:16 -0400
Branch: REL_11_STABLE [25fe401d5] 2021-04-01 13:34:16 -0400
Branch: REL_10_STABLE [1b6961c8f] 2021-04-01 13:34:16 -0400
Branch: REL9_6_STABLE [2c9b857af] 2021-04-01 13:34:16 -0400
-->
     <para>
      Fix missed file version check
      in <application>pg_restore</application> (Tom Lane)
     </para>

     <para>
      When reading a custom-format archive from a non-seekable source,
      <application>pg_restore</application> neglected to check the
      archive version.  If it was fed a newer archive version than it
      can support, it would fail messily later on.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [57c081de0] 2021-04-29 15:24:37 -0400
Branch: REL_13_STABLE [bbcfee0e5] 2021-04-29 15:24:37 -0400
Branch: REL_12_STABLE [ba86371b9] 2021-04-29 15:24:37 -0400
Branch: REL_11_STABLE [404946d40] 2021-04-29 15:24:37 -0400
Branch: REL_10_STABLE [d5722c927] 2021-04-29 15:24:37 -0400
Branch: REL9_6_STABLE [54a233071] 2021-04-29 15:24:38 -0400
-->
     <para>
      Add some more checks to <application>pg_upgrade</application> for
      user tables containing non-upgradable data types (Tom Lane)
     </para>

     <para>
      Fix detection of some cases where a non-upgradable data type is
      embedded within a container type (such as an array or range).
      Also disallow upgrading when user tables contain columns of
      system-defined composite types, since those types' OIDs are not
      stable across versions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [2eb1fc8b1] 2021-04-03 00:07:00 +0900
Branch: REL_13_STABLE [104164361] 2021-04-03 00:07:49 +0900
Branch: REL_12_STABLE [24bcce3bd] 2021-04-03 00:08:05 +0900
-->
     <para>
      Fix incorrect progress-reporting calculation
      in <application>pg_checksums</application> (Shinya Kato)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [51893c846] 2021-03-23 09:53:08 +0900
Branch: REL_13_STABLE [34279fd4f] 2021-03-23 09:54:38 +0900
Branch: REL_12_STABLE [4220e06f4] 2021-03-23 09:54:59 +0900
Branch: REL_11_STABLE [4a2627c41] 2021-03-23 09:55:21 +0900
Branch: REL_10_STABLE [5386a8506] 2021-03-23 09:55:33 +0900
Branch: REL9_6_STABLE [e73068b07] 2021-03-23 09:55:49 +0900
-->
     <para>
      Fix <application>pg_waldump</application> to
      count <literal>XACT</literal> records correctly when generating
      per-record statistics (Kyotaro Horiguchi)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [8deb6b38d] 2021-02-23 17:30:21 -0300
Branch: REL_13_STABLE [28f4b6108] 2021-02-23 17:30:21 -0300
Branch: REL_12_STABLE [2796ae2ad] 2021-02-23 17:30:21 -0300
Branch: REL_11_STABLE [258391707] 2021-02-23 17:30:21 -0300
Branch: REL_10_STABLE [bf518fefa] 2021-02-23 17:30:21 -0300
Branch: REL9_6_STABLE [0ccebe779] 2021-02-23 17:30:21 -0300
-->
     <para>
      Fix <filename>contrib/amcheck</filename> to not complain about the
      tuple flags <literal>HEAP_XMAX_LOCK_ONLY</literal>
      and <literal>HEAP_KEYS_UPDATED</literal> both being set
      (Julien Rouhaud)
     </para>

     <para>
      This is a valid state after <literal>SELECT FOR UPDATE</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [455dbc010] 2021-04-12 19:24:41 -0700
Branch: REL_13_STABLE [13881199e] 2021-04-12 19:24:58 -0700
Branch: REL_12_STABLE [4749c7ff4] 2021-04-12 19:27:09 -0700
Branch: REL_11_STABLE [c8da16ba1] 2021-04-12 19:27:31 -0700
Branch: REL_10_STABLE [fb9812b6c] 2021-04-12 19:27:36 -0700
Branch: REL9_6_STABLE [f488d19f3] 2021-04-12 19:27:38 -0700
-->
     <para>
      Adjust VPATH build rules to support recent Oracle Developer Studio
      compiler versions (Noah Misch)
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [c3556f6fa] 2021-04-12 19:24:21 -0700
Branch: REL_13_STABLE [766c8fce5] 2021-04-12 19:24:24 -0700
Branch: REL_12_STABLE [e3ac7d176] 2021-04-12 19:24:25 -0700
Branch: REL_11_STABLE [4a3de4092] 2021-04-12 19:24:25 -0700
Branch: REL_10_STABLE [72a9bd047] 2021-04-12 19:24:25 -0700
Branch: REL9_6_STABLE [14652a19f] 2021-04-12 19:24:26 -0700
-->
     <para>
      Fix testing of PL/Python for Python 3 on Solaris (Noah Misch)
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-2">
  <title>Release 13.2</title>

  <formalpara>
  <title>Release date:</title>
  <para>2021-02-11</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.1.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.2</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>

   <para>
    However, see the first changelog item below concerning a possible
    need to update stored views.  Also see the third and fourth changelog
    items, which describe cases in which reindexing indexes after the
    upgrade may be advisable.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c028faf2a] 2021-02-08 10:14:09 -0500
Branch: REL_13_STABLE [d525fbcfd] 2021-02-08 10:14:09 -0500
-->
     <para>
      Fix failure to check per-column <literal>SELECT</literal> privileges
      in some join queries (Tom Lane)
     </para>

     <para>
      In some cases involving joins, the parser failed to record all the
      columns read by a query in the column-usage bitmaps that are used
      for permissions checking.  Although the executor would still insist
      on some sort of <literal>SELECT</literal> privilege to run the
      query, this meant that a user having <literal>SELECT</literal>
      privilege on only one column of a table could nonetheless read all
      its columns through a suitably crafted query.
     </para>

     <para>
      A stored view that is subject to this problem will have incomplete
      column-usage bitmaps, and thus permissions will still not be
      enforced properly on the view after updating.  In installations that
      depend on column-level permissions for security, it is recommended
      to <command>CREATE OR REPLACE</command> all user-defined views to
      cause them to be re-parsed.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Sven Klemm for reporting this problem.
      (CVE-2021-20229)
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [6214e2b22] 2021-02-08 11:01:51 +0200
Branch: REL_13_STABLE [8e56684d5] 2021-02-08 11:01:55 +0200
Branch: REL_12_STABLE [f50e88899] 2021-02-08 11:01:55 +0200
Branch: REL_11_STABLE [cb5868cc1] 2021-02-08 11:01:55 +0200
-->
     <para>
      Fix information leakage in constraint-violation error messages
      (Heikki Linnakangas)
     </para>

     <para>
      If an <command>UPDATE</command> command attempts to move a row to a
      different partition but finds that it violates some constraint on
      the new partition, and the columns in that partition are in
      different physical positions than in the parent table, the error
      message could reveal the contents of columns that the user does not
      have <literal>SELECT</literal> privilege on.
      (CVE-2021-3393)
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [6b4d3046f] 2021-01-20 11:58:03 +0200
Branch: REL_13_STABLE [b8403d140] 2021-01-20 11:58:25 +0200
Branch: REL_12_STABLE [0326635dd] 2021-01-20 11:58:27 +0200
-->
     <para>
      Fix incorrect detection of concurrent page splits while inserting
      into a GiST index (Heikki Linnakangas)
     </para>

     <para>
      Concurrent insertions could lead to a corrupt index with entries
      placed in the wrong pages.  It's recommended to reindex any GiST
      index that's been subject to concurrent insertions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [8a54e12a3] 2021-01-30 00:00:27 -0800
Branch: REL_13_STABLE [86a5b309c] 2021-01-30 00:00:42 -0800
Branch: REL_12_STABLE [be843ce29] 2021-01-30 00:01:56 -0800
Branch: REL_11_STABLE [d1ab4bf6e] 2021-01-30 00:02:08 -0800
Branch: REL_10_STABLE [179775135] 2021-01-30 00:02:11 -0800
Branch: REL9_6_STABLE [d683d6528] 2021-01-30 00:04:05 -0800
Branch: REL9_5_STABLE [77a0e14f0] 2021-01-30 00:05:34 -0800
-->
     <para>
      Fix <command>CREATE INDEX CONCURRENTLY</command> to wait for
      concurrent prepared transactions (Andrey Borodin)
     </para>

     <para>
      At the point where <command>CREATE INDEX CONCURRENTLY</command>
      waits for all concurrent transactions to complete so that it can see
      rows they inserted, it must also wait for all prepared transactions
      to complete, for the same reason.  Its failure to do so meant that
      rows inserted by prepared transactions might be omitted from the new
      index, causing queries relying on the index to miss such rows.
      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: Jeff Davis <jdavis@postgresql.org>
Branch: master [05c025896] 2020-12-26 17:25:30 -0800
Branch: REL_13_STABLE [7b8692eaf] 2020-12-26 17:27:50 -0800
Branch: master [fa0fdf051] 2020-12-27 09:48:44 -0800
Branch: REL_13_STABLE [6669cc769] 2020-12-27 12:11:57 -0800
Branch: master [facad3147] 2020-12-27 12:09:00 -0800
Branch: REL_13_STABLE [cd7d8cde7] 2020-12-27 12:11:58 -0800
-->
     <para>
      Avoid crash when trying to rescan an aggregation plan node
      that has both hashed and sorted grouping sets
      (Jeff Davis)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0ff865fbe] 2021-02-04 23:01:37 -0500
Branch: REL_13_STABLE [6467661b6] 2021-02-04 23:01:33 -0500
-->
     <para>
      Fix possible incorrect query results when a hash aggregation node
      spills some tuples to disk (Tom Lane)
     </para>

     <para>
      It was possible for aggregation grouping values to be replaced
      by nulls when the tuples are read back in, leading to wrong answers.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [82e0e2930] 2021-02-04 19:12:14 -0500
Branch: REL_13_STABLE [10fcb83da] 2021-02-04 19:12:09 -0500
-->
     <para>
      Fix edge case in incremental sort (Neil Chen)
     </para>

     <para>
      If the last tuple of a sort batch chanced to be the first tuple of
      the next group of already-sorted tuples, the code did the wrong
      thing.  This could lead to <quote>retrieved too many tuples in a
      bounded sort</quote> error messages, or to silently-wrong sorting
      results.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9624321ec] 2021-02-03 19:38:43 -0500
Branch: REL_13_STABLE [57868d957] 2021-02-03 19:38:29 -0500
Branch: REL_12_STABLE [77e760d5c] 2021-02-03 19:38:29 -0500
Branch: REL_11_STABLE [1c3a87746] 2021-02-03 19:38:29 -0500
-->
     <para>
      Avoid crash when a <literal>CALL</literal> or <literal>DO</literal>
      statement that performs a transaction rollback is executed via
      extended query protocol (Thomas Munro, Tom Lane)
     </para>

     <para>
      In <productname>PostgreSQL</productname> 13, this case reliably
      caused a null-pointer dereference.  In earlier versions the bug
      seems to have no visible symptoms, but it's not quite clear that
      it could never cause a problem.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [6f5c8a8ec] 2021-01-28 16:56:07 -0300
Branch: REL_13_STABLE [16f69062e] 2021-01-28 16:56:07 -0300
-->
     <para>
      Avoid unnecessary errors with <literal>BEFORE UPDATE</literal>
      triggers on partitioned tables (&Aacute;lvaro Herrera)
     </para>

     <para>
      A <literal>BEFORE UPDATE FOR EACH ROW</literal> trigger that
      modified the row in any way prevented <command>UPDATE</command> from
      moving the row to another partition when needed; but there is no
      longer any reason for this restriction.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1d9351a87] 2021-01-28 13:41:55 -0500
Branch: REL_13_STABLE [7f1921cb9] 2021-01-28 13:41:55 -0500
Branch: REL_12_STABLE [7c53a8067] 2021-01-28 13:41:55 -0500
Branch: REL_11_STABLE [6f94531b0] 2021-01-28 13:41:55 -0500
-->
     <para>
      Fix partition pruning logic to handle asymmetric hash partition sets
      (Tom Lane)
     </para>

     <para>
      If a hash-partitioned table has unequally-sized partitions (that is,
      varying modulus values), or it lacks partitions for some remainder
      values, then the planner's pruning logic could mistakenly conclude
      that some partitions don't need to be scanned, leading to failure to
      find rows that the query should find.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a0efda88a] 2021-01-19 13:25:33 -0500
Branch: REL_13_STABLE [188cd4f44] 2021-01-19 13:25:40 -0500
Branch: REL_12_STABLE [625315996] 2021-01-19 13:25:45 -0500
Branch: REL_11_STABLE [794562d07] 2021-01-19 13:25:49 -0500
Branch: REL_10_STABLE [fac54bd5e] 2021-01-19 13:25:54 -0500
Branch: REL9_6_STABLE [fe8edbb82] 2021-01-19 13:26:01 -0500
Branch: REL9_5_STABLE [0ab177bec] 2021-01-19 13:26:05 -0500
-->
     <para>
      Avoid incorrect results when <literal>WHERE CURRENT OF</literal> is
      applied to a cursor whose plan contains a MergeAppend node (Tom
      Lane)
     </para>

     <para>
      This case is unsupported (in general, a cursor using <literal>ORDER
      BY</literal> is not guaranteed to be simply updatable); but the code
      previously did not reject it, and could silently give false matches.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [60661bbf2] 2021-01-18 18:32:30 -0500
Branch: REL_13_STABLE [f0f53195b] 2021-01-18 18:32:40 -0500
Branch: REL_12_STABLE [ba80489c6] 2021-01-18 18:32:45 -0500
Branch: REL_11_STABLE [de622e677] 2021-01-18 18:32:49 -0500
Branch: REL_10_STABLE [5cd94de77] 2021-01-18 18:32:55 -0500
Branch: REL9_6_STABLE [ffbf17463] 2021-01-18 18:33:02 -0500
Branch: REL9_5_STABLE [33a46993f] 2021-01-18 18:33:07 -0500
-->
     <para>
      Fix crash when <literal>WHERE CURRENT OF</literal> is applied to a
      cursor whose plan contains a custom scan node (David Geier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [55dc86eca] 2021-01-21 15:37:23 -0500
Branch: REL_13_STABLE [73fc2e5ba] 2021-01-21 15:37:23 -0500
Branch: REL_12_STABLE [1cce024fd] 2021-01-21 15:37:23 -0500
-->
     <para>
      Fix planner's mishandling of placeholders whose evaluation should be
      delayed by an outer join (Tom Lane)
     </para>

     <para>
      This occurs in particular with trivial subqueries containing lateral
      references to outer-join outputs.  The mistake could result in a
      malformed plan.  The known cases trigger a <quote>failed to assign
      all NestLoopParams to plan nodes</quote> error, but other symptoms
      may be possible.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e98c90099] 2020-12-05 16:16:13 -0500
Branch: REL_13_STABLE [7d43b76f6] 2020-12-05 16:16:13 -0500
Branch: REL_12_STABLE [77a94c30d] 2020-12-05 16:16:13 -0500
-->
     <para>
      Fix planner's handling of placeholders during removal of useless
      RESULT RTEs (Tom Lane)
     </para>

     <para>
      This oversight could lead to <quote>no relation entry for
      relid <replaceable>N</replaceable></quote> planner errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b1738ff6a] 2020-11-30 12:22:43 -0500
Branch: REL_13_STABLE [666a4de93] 2020-11-30 12:22:43 -0500
Branch: REL_12_STABLE [4f728a1f5] 2020-11-30 12:22:43 -0500
Branch: REL_11_STABLE [caecab229] 2020-11-30 12:22:43 -0500
Branch: REL_10_STABLE [785f4462d] 2020-11-30 12:22:43 -0500
Branch: REL9_6_STABLE [ab4cbb4bc] 2020-11-30 12:22:43 -0500
Branch: REL9_5_STABLE [8c5da2d51] 2020-11-30 12:22:43 -0500
-->
     <para>
      Fix planner's handling of a placeholder that is computed at some
      join level and used only at that same level (Tom Lane)
     </para>

     <para>
      This oversight could lead to <quote>failed to build
      any <replaceable>N</replaceable>-way joins</quote> planner errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [f4a3c0b06] 2020-12-21 18:10:20 +0100
Branch: REL_13_STABLE [ea190ed14] 2020-12-21 18:16:36 +0100
-->
     <para>
      Consider unsorted subpaths when planning a Gather Merge operation
      (James Coleman)
     </para>

     <para>
      It's possible to use such a path by adding an explicit Sort node,
      and in some cases that gives rise to a superior plan.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [86b7cca72] 2020-12-21 18:29:49 +0100
Branch: REL_13_STABLE [be9c3cd18] 2020-12-21 18:42:58 +0100
Branch: master [fac1b470a] 2020-12-21 19:36:22 +0100
Branch: REL_13_STABLE [d0167631e] 2020-12-21 19:36:03 +0100
-->
     <para>
      Do not consider <literal>ORDER BY</literal> expressions involving
      parallel-restricted functions or set-returning functions when trying
      to parallelize sorts (James Coleman)
     </para>

     <para>
      Such cases cannot safely be pushed into worker processes, but the
      incremental sort feature accidentally made us consider them.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Gierth <rhodiumtoad@postgresql.org>
Branch: master [660b89928] 2020-11-24 21:58:32 +0000
Branch: REL_13_STABLE [6dda05704] 2020-11-24 21:16:58 +0000
Branch: REL_12_STABLE [ae5aa26dc] 2020-11-24 21:17:02 +0000
Branch: REL_11_STABLE [018e7d98d] 2020-11-24 21:18:37 +0000
Branch: REL_10_STABLE [321c87e5c] 2020-11-24 21:18:59 +0000
Branch: REL9_6_STABLE [6402afd98] 2020-11-24 21:19:50 +0000
Branch: REL9_5_STABLE [59ed45e27] 2020-11-24 21:36:09 +0000
-->
     <para>
      Be more careful about whether index AMs support mark/restore
      (Andrew Gierth)
     </para>

     <para>
      This prevents errors about missing support functions in rare edge
      cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [2ad78a87f] 2021-01-15 12:44:17 +0900
Branch: REL_13_STABLE [60369db86] 2021-01-15 12:45:25 +0900
Branch: REL_12_STABLE [19a1d7685] 2021-01-15 12:45:51 +0900
Branch: REL_11_STABLE [97b025ebe] 2021-01-15 12:46:26 +0900
-->
     <para>
      Fix overestimate of the amount of shared memory needed for parallel
      queries (Takayuki Tsunakawa)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [21378e1fe] 2021-01-20 11:38:17 +0900
Branch: REL_13_STABLE [31e0f9d76] 2021-01-20 11:39:14 +0900
Branch: REL_12_STABLE [5ad672fc2] 2021-01-20 11:39:17 +0900
Branch: REL_11_STABLE [1c3a4d44d] 2021-01-20 11:39:21 +0900
Branch: REL_10_STABLE [74ee3abcf] 2021-01-20 11:39:24 +0900
Branch: REL9_6_STABLE [7dc3be9df] 2021-01-20 11:39:31 +0900
Branch: REL9_5_STABLE [0ddb529cf] 2021-01-20 11:39:35 +0900
-->
     <para>
      Fix <command>ALTER DEFAULT PRIVILEGES</command> to handle duplicated
      arguments safely (Michael Paquier)
     </para>

     <para>
      Duplicate role or schema names within the same command could lead
      to <quote>tuple already updated by self</quote> errors or
      unique-constraint violations.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [08db7c63f] 2020-12-25 10:41:59 -0800
Branch: REL_13_STABLE [9f8a48bb2] 2020-12-25 10:42:02 -0800
Branch: REL_12_STABLE [c96698806] 2020-12-25 10:42:03 -0800
Branch: REL_11_STABLE [e83e8509b] 2020-12-25 10:42:03 -0800
Branch: REL_10_STABLE [d7c197f46] 2020-12-25 10:42:03 -0800
Branch: REL9_6_STABLE [b81d3791e] 2020-12-25 10:42:04 -0800
Branch: REL9_5_STABLE [90383a613] 2020-12-25 10:42:04 -0800
Branch: REL_10_STABLE [d176b9d5e] 2020-12-25 11:02:56 -0800
Branch: REL9_6_STABLE [3f920e876] 2020-12-25 11:03:05 -0800
Branch: REL9_5_STABLE [14649bf50] 2020-12-25 11:06:23 -0800
-->
     <para>
      Flush ACL-related caches when <structname>pg_authid</structname>
      changes (Noah Misch)
     </para>

     <para>
      This change ensures that permissions-related decisions will promptly
      reflect the results of <command>ALTER ROLE ... [NO] INHERIT</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [7da83415e] 2021-01-30 00:12:18 -0800
Branch: REL_13_STABLE [d798ea750] 2021-01-30 00:13:58 -0800
-->
     <para>
      Fix failure to detect <quote>snapshot too old</quote> conditions
      in tables rewritten in the current transaction (Kyotaro Horiguchi,
      Noah Misch)
     </para>

     <para>
      This is only a hazard when <varname>wal_level</varname> is set
      to <literal>minimal</literal> and the rewrite is performed
      by <command>ALTER TABLE SET TABLESPACE</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [360bd2321] 2021-01-30 00:11:38 -0800
Branch: REL_13_STABLE [e8e3e6749] 2021-01-30 00:12:05 -0800
-->
     <para>
      Fix spurious failure of <command>CREATE PUBLICATION</command>
      when applied to a table created or rewritten in the current
      transaction (Kyotaro Horiguchi)
     </para>

     <para>
      This is only a hazard when <varname>wal_level</varname> is set
      to <literal>minimal</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f7f83a55b] 2020-12-01 14:02:27 -0500
Branch: REL_13_STABLE [dffc82a5b] 2020-12-01 14:02:27 -0500
Branch: REL_12_STABLE [5f9b05ada] 2020-12-01 14:02:28 -0500
Branch: REL_11_STABLE [28bb8c496] 2020-12-01 14:02:28 -0500
Branch: REL_10_STABLE [d98e27dc6] 2020-12-01 14:02:28 -0500
Branch: REL9_6_STABLE [f00c44002] 2020-12-01 14:02:28 -0500
Branch: REL9_5_STABLE [fb500296d] 2020-12-01 14:02:28 -0500
-->
     <para>
      Prevent misprocessing of ambiguous <command>CREATE TABLE
      LIKE</command> clauses (Tom Lane)
     </para>

     <para>
      A <literal>LIKE</literal> clause is re-examined after initial
      creation of the new table, to handle importation of indexes and
      such.  It was possible for this re-examination to find a different
      table of the same name, causing unexpected behavior; one example is
      where the new table is a temporary table of the same name as
      the <literal>LIKE</literal> target.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [97390fe8a] 2020-11-19 15:03:17 -0500
Branch: REL_13_STABLE [98f3f1d5c] 2020-11-19 15:03:17 -0500
Branch: REL_12_STABLE [87ab46421] 2020-11-19 15:03:17 -0500
Branch: REL_11_STABLE [c690ebbef] 2020-11-19 15:03:17 -0500
Branch: REL_10_STABLE [513db7b70] 2020-11-19 15:03:17 -0500
Branch: REL9_6_STABLE [159b6775f] 2020-11-19 15:03:17 -0500
Branch: REL9_5_STABLE [6631d5f26] 2020-11-19 15:03:17 -0500
-->
     <para>
      Rearrange order of operations in <command>CREATE TABLE
      LIKE</command> so that indexes are cloned before building foreign
      key constraints (Tom Lane)
     </para>

     <para>
      This fixes the case where a self-referential foreign key constraint
      declared in the outer <command>CREATE TABLE</command> depends on an
      index that's coming from the <literal>LIKE </literal> clause.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [c9a0dc348] 2021-01-15 23:31:22 +0100
Branch: REL_13_STABLE [d26d4c717] 2021-01-15 23:32:54 +0100
Branch: REL_12_STABLE [943a113bc] 2021-01-15 23:33:16 +0100
Branch: REL_11_STABLE [f52db9694] 2021-01-15 23:33:44 +0100
Branch: REL_10_STABLE [c22539756] 2021-01-15 23:34:02 +0100
-->
     <para>
      Disallow <command>CREATE STATISTICS</command> on system catalogs
      (Tomas Vondra)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [dd705a039] 2021-02-06 15:17:01 -0500
Branch: REL_13_STABLE [4353bc878] 2021-02-06 15:17:01 -0500
Branch: REL_12_STABLE [f73321957] 2021-02-06 15:17:01 -0500
Branch: REL_11_STABLE [580069037] 2021-02-06 15:17:02 -0500
Branch: REL_10_STABLE [ad85e5efa] 2021-02-06 15:17:02 -0500
Branch: REL9_6_STABLE [7736ab05f] 2021-02-06 15:17:02 -0500
Branch: REL9_5_STABLE [5ad03374b] 2021-02-06 15:17:02 -0500
-->
     <para>
      Disallow converting an inheritance child table to a view
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [9f35f9437] 2020-12-01 13:21:03 +1300
Branch: REL_13_STABLE [fd3a75d82] 2020-12-01 13:22:01 +1300
Branch: REL_12_STABLE [50f338574] 2020-12-01 13:37:00 +1300
Branch: REL_11_STABLE [d5706ad7b] 2020-12-01 13:46:27 +1300
Branch: REL_10_STABLE [22701755d] 2020-12-01 14:43:04 +1300
Branch: REL9_6_STABLE [d0bbe2122] 2020-12-01 14:50:41 +1300
Branch: REL9_5_STABLE [e00928de8] 2020-12-01 14:54:49 +1300
-->
     <para>
      Ensure that disk space allocated for a dropped relation is released
      promptly at commit (Thomas Munro)
     </para>

     <para>
      Previously, if the dropped relation spanned multiple 1GB segments,
      only the first segment was truncated immediately.  Other segments
      were simply unlinked, which doesn't authorize the kernel to release
      the storage so long as any other backends still have the files open.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [ebfe2dbd6] 2021-01-14 15:32:14 -0300
Branch: REL_13_STABLE [5b01a6f13] 2021-01-14 15:32:14 -0300
Branch: REL_12_STABLE [c9b702552] 2021-01-14 15:32:14 -0300
Branch: REL_11_STABLE [c442b32c2] 2021-01-14 15:32:14 -0300
-->
     <para>
      Prevent dropping a tablespace that is referenced by a partitioned
      relation, but is not used for any actual storage (&Aacute;lvaro
      Herrera)
     </para>

     <para>
      Previously this was allowed, but subsequent operations on the
      partitioned relation would fail.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [3df51ca8b] 2020-11-27 20:16:44 +0900
Branch: REL_13_STABLE [dcc20946a] 2020-11-27 20:17:33 +0900
Branch: REL_12_STABLE [fce17e486] 2020-11-27 20:18:02 +0900
-->
     <para>
      Fix progress reporting for <command>CLUSTER</command> (Matthias van
      de Meent)
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [c444472af] 2021-02-05 11:14:56 +0200
Branch: REL_13_STABLE [c87cbd51e] 2021-02-05 11:19:48 +0200
Branch: REL_12_STABLE [9b0ce8957] 2021-02-05 11:16:33 +0200
Branch: REL_11_STABLE [d9b4163c5] 2021-02-05 11:16:53 +0200
Branch: REL_10_STABLE [c06632e48] 2021-02-05 11:17:07 +0200
Branch: REL9_6_STABLE [e152ccc7f] 2021-02-05 11:17:13 +0200
Branch: REL9_5_STABLE [aaf266157] 2021-02-05 11:17:27 +0200
-->
     <para>
      Fix handling of backslash-escaped multibyte characters
      in <command>COPY FROM</command> (Heikki Linnakangas)
     </para>

     <para>
      A backslash followed by a multibyte character was not handled
      correctly.  In some client character encodings, this could lead to
      misinterpreting part of a multibyte character as a field separator
      or end-of-copy-data marker.
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [2cccb627f] 2020-11-18 12:39:15 +0200
Branch: REL_13_STABLE [340ae3cfb] 2020-11-20 14:41:14 +0200
Branch: REL_12_STABLE [888fa2bae] 2020-11-20 14:46:47 +0200
Branch: REL_11_STABLE [57b5d8484] 2020-11-20 14:49:25 +0200
Branch: REL_10_STABLE [1dbe627fd] 2020-11-20 14:49:42 +0200
Branch: REL9_6_STABLE [02a2dbe91] 2020-11-20 14:57:15 +0200
Branch: REL9_5_STABLE [ded7db4c1] 2020-11-20 14:57:51 +0200
-->
     <para>
      Avoid preallocating executor hash tables
      in <command>EXPLAIN</command> without <literal>ANALYZE</literal>
      (Alexey Bashtanov)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9c83b54a9] 2020-11-28 14:03:40 -0500
Branch: REL_13_STABLE [f5de090cc] 2020-11-28 14:03:40 -0500
Branch: REL_12_STABLE [cbc7a7a10] 2020-11-28 14:03:40 -0500
Branch: REL_11_STABLE [40f2fbe71] 2020-11-28 14:03:40 -0500
Branch: REL_10_STABLE [f6324bbbe] 2020-11-28 14:03:40 -0500
Branch: REL9_6_STABLE [8a4069766] 2020-11-28 14:03:40 -0500
Branch: REL9_5_STABLE [60d6c7143] 2020-11-28 14:03:40 -0500
-->
     <para>
      Fix recently-introduced race condition
      in <command>LISTEN</command>/<command>NOTIFY</command> queue
      handling (Tom Lane)
     </para>

     <para>
      A newly-listening backend could attempt to read SLRU pages that
      were in process of being truncated, possibly causing an error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ff5d5611c] 2020-12-21 13:11:50 -0500
Branch: REL_13_STABLE [38d30a14b] 2020-12-21 13:11:51 -0500
Branch: REL_12_STABLE [38bef9e43] 2020-12-21 13:11:29 -0500
Branch: REL_11_STABLE [75c8ef5ae] 2020-12-21 13:11:29 -0500
Branch: REL_10_STABLE [542248f9d] 2020-12-21 13:11:30 -0500
Branch: REL9_6_STABLE [1d5f3f976] 2020-12-21 13:11:30 -0500
Branch: REL9_5_STABLE [edcdbc44e] 2020-12-21 13:11:30 -0500
-->
     <para>
      Allow the <type>jsonb</type> concatenation operator to handle all
      combinations of JSON data types (Tom Lane)
     </para>

     <para>
      We can concatenate two JSON objects or two JSON arrays.  Handle
      other cases by wrapping non-array inputs in one-element arrays,
      then performing an array concatenation.  Previously, some
      combinations of inputs followed this rule but others arbitrarily
      threw an error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [afcc8772e] 2021-01-08 12:16:00 -0500
Branch: REL_13_STABLE [49c928c0c] 2021-01-08 12:16:00 -0500
Branch: REL_12_STABLE [8354371d0] 2021-01-08 12:16:00 -0500
Branch: REL_11_STABLE [769908811] 2021-01-08 12:16:00 -0500
Branch: REL_10_STABLE [2d540ac5f] 2021-01-08 12:16:00 -0500
Branch: REL9_6_STABLE [085a1cfb3] 2021-01-08 12:16:00 -0500
Branch: REL9_5_STABLE [0c23f30fa] 2021-01-08 12:16:00 -0500
-->
     <para>
      Fix use of uninitialized value while parsing a <literal>*</literal>
      quantifier in a BRE-mode regular expression (Tom Lane)
     </para>

     <para>
      This error could cause the quantifier to act non-greedy, that is
      behave like a <literal>*?</literal> quantifier would do in full
      regular expressions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [bc43b7c2c] 2021-01-05 11:15:28 +0000
Branch: REL_13_STABLE [e15c384d7] 2021-01-05 11:08:59 +0000
Branch: REL_12_STABLE [258b77005] 2021-01-05 11:07:12 +0000
Branch: REL_11_STABLE [160a9e425] 2021-01-05 11:05:58 +0000
Branch: REL_10_STABLE [275b190b3] 2021-01-05 11:04:41 +0000
Branch: REL9_6_STABLE [9a299dff2] 2021-01-05 11:02:46 +0000
Branch: master [fead67c24] 2021-01-05 11:52:42 +0000
Branch: REL_13_STABLE [5777b6ea2] 2021-01-05 11:51:21 +0000
Branch: REL_12_STABLE [740780a61] 2021-01-05 11:50:11 +0000
Branch: REL_11_STABLE [ab042d010] 2021-01-05 11:48:45 +0000
Branch: REL_10_STABLE [0097193b1] 2021-01-05 11:46:44 +0000
Branch: REL9_6_STABLE [f0b9bada5] 2021-01-05 11:45:17 +0000
-->
     <para>
      Fix numeric <function>power()</function> for the case where the
      exponent is exactly <literal>INT_MIN</literal> (-2147483648)
      (Dean Rasheed)
     </para>

     <para>
      Previously, a result with no significant digits was produced.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4bd3fad80] 2021-01-04 18:32:44 -0500
Branch: REL_13_STABLE [9e7d87ca8] 2021-01-04 18:32:40 -0500
Branch: REL_12_STABLE [7c98759e0] 2021-01-04 18:32:40 -0500
Branch: REL_11_STABLE [50a420bee] 2021-01-04 18:32:40 -0500
-->
     <para>
      Fix integer-overflow cases in <function>substring()</function>
      functions (Tom Lane, Pavel Stehule)
     </para>

     <para>
      If the specified starting index and length overflow an integer when
      added together, <function>substring()</function> misbehaved, either
      throwing a bogus <quote>negative substring length</quote> error for
      a case that should succeed, or failing to complain that a negative
      length is negative (and instead returning the whole string, in most
      cases).
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [6db992833] 2021-01-16 12:21:35 -0800
Branch: REL_13_STABLE [6eb3fc7fc] 2021-01-16 12:21:38 -0800
Branch: REL_12_STABLE [66087f7e9] 2021-01-16 12:21:39 -0800
Branch: REL_11_STABLE [677f6cb1d] 2021-01-16 12:21:39 -0800
Branch: REL_10_STABLE [9afba9b0e] 2021-01-16 12:21:39 -0800
Branch: REL9_6_STABLE [1a31d8c52] 2021-01-16 12:21:39 -0800
Branch: REL9_5_STABLE [c424c75f5] 2021-01-16 12:21:39 -0800
-->
     <para>
      Prevent possible data loss from incorrect detection of the
      wraparound point of an SLRU log
      (Noah Misch)
     </para>

     <para>
      The wraparound point typically falls in the middle of a page, which
      must be rounded off to a page boundary, and that was not done
      correctly.  No issue could arise unless an installation had gotten
      to within one page of SLRU overflow, which is unlikely in a
      properly-functioning system.  If this did happen, it would manifest
      in later <quote>apparent wraparound</quote> or <quote>could not
      access status of transaction</quote> errors.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [fef5b47f6] 2021-01-14 12:27:11 +0900
Branch: REL_13_STABLE [94f52929a] 2021-01-14 12:28:47 +0900
Branch: master [424d7a9b2] 2021-01-14 23:55:33 +0900
Branch: REL_13_STABLE [8523a0971] 2021-01-14 23:56:45 +0900
-->
     <para>
      Fix WAL-reading logic to handle timeline switches correctly (Kyotaro
      Horiguchi, Fujii Masao)
     </para>

     <para>
      Previously, if WAL archiving is enabled, a standby could fail to
      follow a primary running on a newer timeline, with errors
      like <quote>requested WAL segment has already been removed</quote>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [ee1b38f65] 2021-01-13 08:19:50 +0530
Branch: REL_13_STABLE [0685c5c1b] 2021-01-13 08:31:45 +0530
Branch: REL_12_STABLE [0b2ae3c92] 2021-01-13 08:40:06 +0530
Branch: REL_11_STABLE [7adc408f4] 2021-01-13 08:50:13 +0530
Branch: REL_10_STABLE [636b6f99c] 2021-01-13 09:01:57 +0530
Branch: REL9_6_STABLE [f2b268ee0] 2021-01-13 09:12:59 +0530
Branch: REL9_5_STABLE [4bccceaa9] 2021-01-13 09:22:03 +0530
-->
     <para>
      Fix memory leak in walsender processes while sending new snapshots
      for logical decoding (Amit Kapila)
     </para>
    </listitem>

    <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [044aa9e70] 2021-01-12 08:19:39 +0530
Branch: REL_13_STABLE [decf3fe61] 2021-01-12 08:30:16 +0530
-->
     <para>
      Fix relation cache leak in walsender processes while sending row
      changes via the root of a partitioned relation during logical
      replication (Amit Langote, Mark Zhao)
     </para>
    </listitem>

    <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [a58db3aa1] 2020-12-14 23:47:30 -0800
Branch: REL_13_STABLE [fde5f130c] 2020-12-14 23:48:44 -0800
Branch: REL_12_STABLE [706d84fe7] 2020-12-14 23:48:04 -0800
Branch: REL_11_STABLE [4ee058a3b] 2020-12-14 23:49:06 -0800
Branch: REL_10_STABLE [ac7df6e8f] 2020-12-14 23:49:29 -0800
Branch: REL9_6_STABLE [f10da1e9c] 2020-12-14 23:49:57 -0800
Branch: REL9_5_STABLE [133a0906d] 2020-12-14 23:50:20 -0800
-->
     <para>
      Fix walsender to accept additional commands after
      terminating replication (Jeff Davis)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [8900b5a9d] 2021-01-06 12:39:18 +0900
Branch: REL_13_STABLE [0f8977b3f] 2021-01-06 12:30:37 +0900
Branch: REL_12_STABLE [9f540f840] 2021-01-06 12:31:23 +0900
Branch: REL_11_STABLE [e83771880] 2021-01-06 12:31:55 +0900
Branch: REL_10_STABLE [4c20e78f1] 2021-01-06 12:32:32 +0900
Branch: REL9_6_STABLE [0307b98d8] 2021-01-06 12:33:28 +0900
-->
     <para>
      Ensure detection of deadlocks between hot standby backends and the
      startup (WAL-application) process (Fujii Masao)
     </para>

     <para>
      The startup process did not run the deadlock detection code, so that
      in situations where the startup process is last to join a circular
      wait situation, the deadlock might never be recognized.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [422881744] 2020-12-30 16:29:05 -0800
Branch: REL_13_STABLE [7a57960ba] 2020-12-30 16:29:03 -0800
Branch: REL_12_STABLE [4f70e0910] 2020-12-30 16:29:01 -0800
Branch: master [32d6287d2] 2020-12-30 17:21:42 -0800
Branch: REL_13_STABLE [55e535226] 2020-12-30 17:21:41 -0800
Branch: REL_12_STABLE [5f95664e1] 2020-12-30 17:21:39 -0800
-->
     <para>
      Fix possible failure to detect recovery conflicts while deleting an
      index entry that references a HOT chain (Peter Geoghegan)
     </para>

     <para>
      The code failed to traverse the HOT chain and might thus compute a
      too-old XID horizon, which could lead to incorrect conflict
      processing in hot standby.  The practical impact of this bug is
      limited; in most cases the correct XID horizon would be found anyway
      from nearby operations.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [860fe27ee] 2020-12-30 11:38:42 -0500
Branch: REL_13_STABLE [861e96717] 2020-12-30 11:38:42 -0500
Branch: REL_12_STABLE [3ca19490b] 2020-12-30 11:38:42 -0500
-->
     <para>
      Ensure that a nonempty value
      of <varname>krb_server_keyfile</varname> always overrides any
      setting of <varname>KRB5_KTNAME</varname> in the server's
      environment (Tom Lane)
     </para>

     <para>
      Previously, which setting took precedence depended on whether the
      client requests GSS encryption.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3995c4249] 2020-12-28 17:58:58 -0500
Branch: REL_13_STABLE [d05e14d78] 2020-12-28 17:58:58 -0500
Branch: REL_12_STABLE [7ed616f81] 2020-12-28 17:58:58 -0500
-->
     <para>
      In server log messages about failing to match connections
      to <filename>pg_hba.conf</filename> entries, include details about
      whether GSS encryption has been activated (Kyotaro Horiguchi, Tom
      Lane)
     </para>

     <para>
      This is relevant data if <literal>hostgssenc</literal>
      or <literal>hostnogssenc</literal> entries exist.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [622ae4621] 2020-12-28 17:44:17 -0500
Branch: REL_13_STABLE [c1c88bf03] 2020-12-28 17:44:17 -0500
Branch: REL_12_STABLE [4cfdd8a47] 2020-12-28 17:44:17 -0500
-->
     <para>
      Fix assorted issues in server's support for GSS encryption (Tom Lane)
     </para>

     <para>
      Remove pointless restriction that only GSS authentication
      can be used on a GSS-encrypted connection.
      Add GSS encryption information to connection-authorized log messages.
      Include GSS-related space when computing the required size of
      shared memory (this omission could have caused problems with very
      high <varname>max_connections</varname> settings).
      Avoid possible infinite recursion when reporting an unrecoverable
      GSS encryption error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7519bd16d] 2020-12-24 17:00:43 -0500
Branch: REL_13_STABLE [0217ad806] 2020-12-24 17:00:43 -0500
Branch: REL_12_STABLE [3d8068edc] 2020-12-24 17:00:43 -0500
Branch: REL_11_STABLE [b99b6b9d6] 2020-12-24 17:00:43 -0500
Branch: REL_10_STABLE [1a6b1c460] 2020-12-24 17:00:43 -0500
-->
     <para>
      Ensure that unserviced requests for background workers are cleaned
      up when the postmaster begins a <quote>smart</quote>
      or <quote>fast</quote> shutdown sequence (Tom Lane)
     </para>

     <para>
      Previously, there was a race condition whereby a child process that
      had requested a background worker just before shutdown could wait
      indefinitely, preventing shutdown from completing.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [6db27037b] 2020-12-23 12:51:22 +0900
Branch: REL_13_STABLE [1e54664ee] 2020-12-23 12:51:35 +0900
Branch: REL_12_STABLE [67a9411d2] 2020-12-23 12:51:39 +0900
Branch: REL_11_STABLE [35ad5c7c7] 2020-12-23 12:51:42 +0900
Branch: REL_10_STABLE [f3ee99df7] 2020-12-23 12:51:46 +0900
Branch: REL9_6_STABLE [0b54a80a3] 2020-12-23 12:51:51 +0900
-->
     <para>
      Fix portability problem in parsing
      of <varname>recovery_target_xid</varname> values (Michael Paquier)
     </para>

     <para>
      The target XID is potentially 64 bits wide, but it was parsed
      with <function>strtoul()</function>, causing misbehavior on
      platforms where <type>long</type> is 32 bits (such as Windows).
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [275b3411d] 2020-11-30 14:38:00 -0500
Branch: REL_13_STABLE [fac31b2cd] 2020-11-30 14:38:00 -0500
Branch: REL_12_STABLE [16a1e1ea4] 2020-11-30 14:38:00 -0500
Branch: REL_11_STABLE [942e441ee] 2020-11-30 14:38:00 -0500
-->
     <para>
      Avoid trying to use parallel index build in a standalone backend
      (Yulin Pei)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [29d29d652] 2020-11-15 16:10:58 -0500
Branch: REL_13_STABLE [7c89246d0] 2020-11-15 16:10:48 -0500
Branch: REL_12_STABLE [4ac8ee9d4] 2020-11-15 16:10:48 -0500
Branch: REL_11_STABLE [9cebe4952] 2020-11-15 16:10:48 -0500
-->
     <para>
      Allow index AMs to support included columns without necessarily
      supporting multiple key columns (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [03f9cd93e] 2020-11-12 10:56:33 +0900
Branch: REL_13_STABLE [9a94b9253] 2020-11-12 10:56:40 +0900
-->
     <para>
      While taking a base backup, avoid executing any SHA256 code if a
      backup manifest is not needed (Michael Paquier)
     </para>

     <para>
      When using OpenSSL operating in FIPS mode, SHA256 hashing is
      rejected, leading to an error.  This change makes it possible to
      take a base backup on such a platform, so long
      as <option>--no-manifest</option> is specified.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Gierth <rhodiumtoad@postgresql.org>
Branch: master [a3367aa3c] 2021-01-28 10:53:10 +0000
Branch: REL_13_STABLE [75e3cca42] 2021-01-28 11:09:40 +0000
Branch: REL_12_STABLE [30f912a41] 2021-01-28 11:09:49 +0000
Branch: REL_11_STABLE [f7f2a28d4] 2021-01-28 11:09:57 +0000
-->
     <para>
      Avoid assertion failure during parallel aggregation of an
      aggregate with a non-strict deserialization function (Andrew Gierth)
     </para>

     <para>
      No such aggregate functions exist in
      core <productname>PostgreSQL</productname>, but some extensions
      such as PostGIS provide some.  The mistake is harmless anyway in a
      non-assert build.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [07d46fceb] 2021-01-25 13:03:43 -0500
Branch: REL_13_STABLE [a26194f22] 2021-01-25 13:03:11 -0500
Branch: REL_12_STABLE [4641b2a30] 2021-01-25 13:03:11 -0500
Branch: REL_11_STABLE [a7cdd3f71] 2021-01-25 13:03:11 -0500
Branch: REL_10_STABLE [d09e8789f] 2021-01-25 13:03:11 -0500
Branch: REL9_6_STABLE [57a7d6f49] 2021-01-25 13:03:12 -0500
Branch: REL9_5_STABLE [41309f716] 2021-01-25 13:03:12 -0500
-->
     <para>
      Avoid assertion failure in <function>pg_get_functiondef()</function>
      when examining a function with a <literal>TRANSFORM</literal> option
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ea80d8d94] 2020-12-28 11:41:25 -0500
Branch: REL_13_STABLE [0ea25ed10] 2020-12-28 11:41:25 -0500
Branch: REL_12_STABLE [fd1347f9d] 2020-12-28 11:41:25 -0500
Branch: REL_11_STABLE [2e15f48d9] 2020-12-28 11:41:25 -0500
Branch: master [5f2e09bcc] 2020-12-28 11:55:23 -0500
Branch: REL_13_STABLE [63d78d106] 2020-12-28 11:55:32 -0500
Branch: REL_12_STABLE [d37965965] 2020-12-28 11:55:37 -0500
Branch: REL_11_STABLE [7966b41de] 2020-12-28 11:55:41 -0500
-->
     <para>
      Fix data structure misallocation in
      PL/pgSQL's <command>CALL</command> statement (Tom Lane)
     </para>

     <para>
      A <command>CALL</command> in a PL/pgSQL procedure, to another
      procedure that has OUT parameters, would fail if the called
      procedure did a <command>COMMIT</command>
      or <command>ROLLBACK</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ff6ce9a3a] 2020-12-28 15:43:44 -0500
Branch: REL_13_STABLE [06b844c2b] 2020-12-28 15:43:44 -0500
Branch: REL_12_STABLE [b3a5bf719] 2020-12-28 15:43:44 -0500
-->
     <para>
      In <application>libpq</application>, do not skip trying SSL after
      GSS encryption (Tom Lane)
     </para>

     <para>
      If we successfully made a GSS-encrypted connection, but then failed
      during authentication, we would fall back to an unencrypted
      connection rather than next trying an SSL-encrypted connection.
      This could lead to unexpected connection failure, or to silently
      getting an unencrypted connection where an encrypted one is
      expected.  Fortunately, GSS encryption could only succeed if both
      client and server hold valid tickets in the same Kerberos
      infrastructure.  It seems unlikely for that to be true in an
      environment that requires SSL encryption instead.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [cf61b0734] 2020-12-28 12:13:40 -0500
Branch: REL_13_STABLE [31d2b11b9] 2020-12-28 12:13:40 -0500
-->
     <para>
      Make <application>libpq</application>'s
      <function>PQconndefaults()</function> function report the correct
      default value for <varname>channel_binding</varname>
      (Daniele Varrazzo)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7e5e1bba0] 2020-11-29 15:22:04 -0500
Branch: REL_13_STABLE [72b930f50] 2020-11-29 15:22:04 -0500
Branch: REL_12_STABLE [3958abdad] 2020-11-29 15:22:04 -0500
Branch: REL_11_STABLE [777ac03a6] 2020-11-29 15:22:04 -0500
Branch: REL_10_STABLE [946277fd4] 2020-11-29 15:22:04 -0500
Branch: REL9_6_STABLE [3f59a05f0] 2020-11-29 15:22:04 -0500
Branch: REL9_5_STABLE [e2d5de150] 2020-11-29 15:22:04 -0500
-->
     <para>
      In <application>psql</application>, re-allow including a password
      in a <replaceable>connection_string</replaceable> argument of a
      <command>\connect</command> command (Tom Lane)
     </para>

     <para>
      This used to work, but a recent bug fix caused the password to be
      ignored (resulting in prompting for a password).
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [314fb9bae] 2020-11-25 16:19:25 -0500
Branch: REL_13_STABLE [a0ef08172] 2020-11-25 16:19:25 -0500
Branch: REL_12_STABLE [ea7a167da] 2020-11-25 16:19:25 -0500
-->
     <para>
      In <application>psql</application>'s <command>\d</command> commands,
      don't truncate the display of column default values (Tom Lane)
     </para>

     <para>
      Formerly, they were arbitrarily truncated at 128 characters.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f76a85000] 2021-01-26 13:04:52 -0500
Branch: REL_13_STABLE [64bdb6e5f] 2021-01-26 13:04:52 -0500
Branch: REL_12_STABLE [82f97d33f] 2021-01-26 13:04:52 -0500
Branch: REL_11_STABLE [3fa7b9078] 2021-01-26 13:04:52 -0500
Branch: REL_10_STABLE [564cb2579] 2021-01-26 13:04:52 -0500
Branch: REL9_6_STABLE [2c2e134b7] 2021-01-26 13:04:52 -0500
Branch: REL9_5_STABLE [131825cd5] 2021-01-26 13:04:52 -0500
-->
     <para>
      Fix assorted bugs
      in <application>psql</application>'s <command>\help</command>
      command (Kyotaro Horiguchi, Tom Lane)
     </para>

     <para>
      <command>\help</command> with two argument words failed to find a
      command description using only the first word, for
      example <literal>\help reset all</literal> should show the help
      for <command>RESET</command> but did not.
      Also, <command>\help</command> often failed to invoke the pager when
      it should.  It also leaked memory.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [0bf83648a] 2021-02-03 11:27:13 +0100
Branch: REL_13_STABLE [1d3ce0223] 2021-02-03 11:43:01 +0100
Branch: REL_12_STABLE [1dd6baf78] 2021-02-03 11:58:15 +0100
-->
     <para>
      Fix <application>pg_dump</application>'s dumping of inherited
      generated columns (Peter Eisentraut)
     </para>

     <para>
      The previous behavior resulted in (harmless) errors during restore.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9eabfe300] 2021-01-12 13:37:38 -0500
Branch: REL_13_STABLE [0011c5a0f] 2021-01-12 13:37:38 -0500
Branch: REL_12_STABLE [436d9c5ca] 2021-01-12 13:37:38 -0500
Branch: REL_11_STABLE [9f15188a1] 2021-01-12 13:37:38 -0500
Branch: master [8e396a773] 2021-01-14 16:19:38 -0500
Branch: REL_13_STABLE [79d3ac72f] 2021-01-14 16:19:38 -0500
Branch: REL_12_STABLE [0d221ecec] 2021-01-14 16:19:38 -0500
Branch: REL_11_STABLE [bb12a7f42] 2021-01-14 16:19:38 -0500
Branch: REL_10_STABLE [1c9791f66] 2021-01-14 16:19:38 -0500
-->
     <para>
      In <application>pg_dump</application>, ensure that the restore
      script runs <command>ALTER PUBLICATION ADD TABLE</command> commands
      as the owner of the publication, and similarly runs <command>ALTER
      INDEX ATTACH PARTITION</command> commands as the owner of the
      partitioned index (Tom Lane)
     </para>

     <para>
      Previously, these commands would be run by the role that started the
      restore script; which will usually work, but in corner cases that
      role might not have adequate permissions.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [f713ff7c6] 2021-01-16 12:21:35 -0800
Branch: REL_13_STABLE [b8daf894f] 2021-01-16 12:21:38 -0800
Branch: REL_12_STABLE [a0d31b1c9] 2021-01-16 12:21:39 -0800
Branch: REL_11_STABLE [c6ff165f9] 2021-01-16 12:21:39 -0800
Branch: REL_10_STABLE [b933c9c0b] 2021-01-16 12:21:39 -0800
Branch: REL9_6_STABLE [ad2b7c9bb] 2021-01-16 12:21:39 -0800
-->
     <para>
      Fix <application>pg_dump</application> to handle <literal>WITH
      GRANT OPTION</literal> in an extension's initial privileges
      (Noah Misch)
     </para>

     <para>
      If an extension's script creates an object and grants privileges
      on it with grant option, then later the user revokes such
      privileges, <application>pg_dump</application> would generate
      incorrect SQL for reproducing the situation.  (Few if any extensions
      do this today.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [2b4f31303] 2020-12-03 15:57:48 +0200
Branch: REL_13_STABLE [abd0abfb7] 2020-12-03 15:57:52 +0200
Branch: REL_12_STABLE [020f153db] 2020-12-03 15:57:54 +0200
Branch: REL_11_STABLE [63e316f0b] 2020-12-03 15:57:57 +0200
Branch: REL_10_STABLE [8b5c353ec] 2020-12-03 15:58:00 +0200
Branch: REL9_6_STABLE [0740857de] 2020-12-03 15:58:02 +0200
Branch: REL9_5_STABLE [81e3c868f] 2020-12-03 15:58:06 +0200
Branch: master [36a4ac20f] 2020-12-04 18:26:46 +0200
Branch: REL_13_STABLE [e41a2efbc] 2020-12-04 18:24:34 +0200
Branch: REL_12_STABLE [ad3fb04b9] 2020-12-04 18:24:57 +0200
Branch: REL_11_STABLE [cda50f211] 2020-12-04 18:25:12 +0200
Branch: REL_10_STABLE [45d363145] 2020-12-04 18:25:23 +0200
Branch: REL9_6_STABLE [a075c84f2] 2020-12-04 18:25:45 +0200
Branch: REL9_5_STABLE [1dd608bba] 2020-12-04 18:25:54 +0200
Branch: master [6ba581cf1] 2020-12-07 14:50:20 +0200
Branch: REL_13_STABLE [e6dc04d43] 2020-12-07 14:50:37 +0200
Branch: REL_12_STABLE [98f8cdd48] 2020-12-07 14:55:22 +0200
Branch: REL_11_STABLE [10d9c9d03] 2020-12-07 14:55:23 +0200
Branch: REL_10_STABLE [d137b14c3] 2020-12-07 14:55:25 +0200
Branch: REL9_6_STABLE [3ea8e660c] 2020-12-07 14:55:27 +0200
Branch: REL9_5_STABLE [beb6b45ab] 2020-12-07 14:55:28 +0200
-->
     <para>
      In <application>pg_rewind</application>, ensure that all WAL is
      accounted for when rewinding a standby server
      (Ian Barwick, Heikki Linnakangas)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c21ea4d53] 2021-01-13 14:52:59 -0500
Branch: REL_13_STABLE [6b045ca6c] 2021-01-13 14:52:49 -0500
Branch: REL_12_STABLE [3e214fafc] 2021-01-13 14:52:49 -0500
Branch: REL_11_STABLE [d8bb22ab3] 2021-01-13 14:52:49 -0500
-->
     <para>
      In <application>pgbench</application>, disallow a digit as the first
      character of a variable name (Fabien Coelho)
     </para>

     <para>
      This prevents trying to substitute variables into timestamp literal
      values, which may contain strings like <literal>12:34</literal>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: REL_13_STABLE [f17e8f33f] 2021-01-26 16:42:13 -0300
Branch: REL_12_STABLE [fdf9d0054] 2021-01-26 16:42:13 -0300
Branch: REL_11_STABLE [fdd405c63] 2021-01-26 16:42:13 -0300
Branch: REL_10_STABLE [11a708f81] 2021-01-26 16:42:13 -0300
Branch: REL9_6_STABLE [bcae842b9] 2021-01-26 16:42:13 -0300
Branch: REL9_5_STABLE [f2dc96236] 2021-01-26 16:42:13 -0300
-->
     <para>
      Report the correct database name in connection failure error
      messages from some client programs (&Aacute;lvaro Herrera)
     </para>

     <para>
      If the database name was defaulted rather than given on the command
      line, <application>pg_dumpall</application>,
      <application>pgbench</application>, <application>oid2name</application>,
      and <application>vacuumlo</application> would produce misleading
      error messages after a connection failure.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5c0f7cc54] 2021-02-02 13:49:08 -0500
Branch: REL_13_STABLE [586891394] 2021-02-02 13:49:08 -0500
Branch: REL_12_STABLE [742846958] 2021-02-02 13:49:08 -0500
Branch: REL_11_STABLE [5fc5ff61c] 2021-02-02 13:49:08 -0500
Branch: REL_10_STABLE [2671125c7] 2021-02-02 13:49:08 -0500
Branch: REL9_6_STABLE [608cf2bfd] 2021-02-02 13:49:08 -0500
Branch: REL9_5_STABLE [f0f9ed68d] 2021-02-02 13:49:08 -0500
-->
     <para>
      Fix memory leak in <filename>contrib/auto_explain</filename>
      (Japin Li)
     </para>

     <para>
      Memory consumed while producing the <literal>EXPLAIN</literal>
      output was not freed until the end of the current transaction (for a
      top-level statement) or the end of the surrounding statement (for a
      nested statement).  This was particularly a problem
      with <varname>log_nested_statements</varname> enabled.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [e3ebcca84] 2020-12-28 19:56:13 +0900
Branch: REL_13_STABLE [546f14374] 2020-12-28 19:57:51 +0900
Branch: REL_12_STABLE [e792ca4ac] 2020-12-28 19:59:00 +0900
Branch: REL_11_STABLE [294cdd7d0] 2020-12-28 19:59:40 +0900
Branch: REL_10_STABLE [744357d84] 2020-12-28 20:00:15 +0900
Branch: REL9_6_STABLE [03b7a1ee7] 2020-12-28 20:00:54 +0900
Branch: REL9_5_STABLE [b5c73eef8] 2020-12-28 20:01:31 +0900
-->
     <para>
      In <filename>contrib/postgres_fdw</filename>, avoid leaking open
      connections to remote servers when a user mapping or foreign server
      object is dropped (Bharath Rupireddy)
     </para>

     <para>
      Open connections that depend on a dropped user mapping or foreign
      server can no longer be referenced, but formerly they were kept
      around anyway for the duration of the local session.
     </para>
    </listitem>

    <listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [5e7fa189e] 2021-02-05 15:30:00 +0900
Branch: REL_13_STABLE [984384129] 2021-02-05 15:30:02 +0900
-->
     <para>
      Fix faulty assertion in <filename>contrib/postgres_fdw</filename>
      (Etsuro Fujita)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [28d1601ad] 2020-12-08 15:22:12 +0900
Branch: REL_13_STABLE [dfd8bf2b9] 2020-12-08 15:22:38 +0900
Branch: REL_12_STABLE [d7ecba937] 2020-12-08 15:22:43 +0900
Branch: REL_11_STABLE [b88afd8b6] 2020-12-08 15:22:48 +0900
Branch: REL_10_STABLE [5ba1df0f1] 2020-12-08 15:22:53 +0900
Branch: REL9_6_STABLE [95992e5ed] 2020-12-08 15:22:59 +0900
Branch: REL9_5_STABLE [f95d9fd81] 2020-12-08 15:23:02 +0900
-->
     <para>
      In <filename>contrib/pgcrypto</filename>, check for error returns
      from OpenSSL's EVP functions (Michael Paquier)
     </para>

     <para>
      We do not really expect errors here, but this change silences
      warnings from static analysis tools.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ff769831e] 2020-12-22 13:23:49 -0500
Branch: REL_13_STABLE [4b0292253] 2020-12-22 13:23:49 -0500
Branch: REL_12_STABLE [f581e5383] 2020-12-22 13:23:49 -0500
Branch: REL_11_STABLE [a1bd14d54] 2020-12-22 13:23:49 -0500
-->
     <para>
      Make <filename>contrib/pg_prewarm</filename> more robust when the
      cluster is shut down before prewarming is complete (Tom Lane)
     </para>

     <para>
      Previously, autoprewarm would rewrite its status file with only the
      block numbers that it had managed to load so far, thus perhaps
      largely disabling the prewarm functionality in the next startup.
      Instead, suppress status file updates until the initial loading pass
      is complete.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Gierth <rhodiumtoad@postgresql.org>
Branch: master [3836d4b64] 2020-11-12 14:34:37 +0000
Branch: REL_13_STABLE [48ab1fa30] 2020-11-12 14:59:06 +0000
Branch: REL_12_STABLE [7f69ed4ae] 2020-11-12 14:56:58 +0000
Branch: REL_11_STABLE [7e3dc147d] 2020-11-12 14:57:04 +0000
Branch: REL_10_STABLE [068de9dd4] 2020-11-12 14:57:08 +0000
Branch: REL9_6_STABLE [245a35f96] 2020-11-12 14:57:13 +0000
Branch: REL9_5_STABLE [4b212b7c8] 2020-11-12 14:55:51 +0000
-->
     <para>
      In <filename>contrib/pg_trgm</filename>'s GiST index support, avoid
      crash in the rare case that picksplit is called on exactly two index
      items (Andrew Gierth, Alexander Korotkov)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ec29427ce] 2020-11-10 22:51:54 -0500
Branch: REL_13_STABLE [afce7908d] 2020-11-10 22:51:55 -0500
Branch: REL_12_STABLE [171c457cd] 2020-11-10 22:51:55 -0500
Branch: REL_11_STABLE [3a89ea0eb] 2020-11-10 22:51:56 -0500
Branch: REL_10_STABLE [e87139b43] 2020-11-10 22:51:57 -0500
Branch: REL9_6_STABLE [cd39c23a2] 2020-11-10 22:51:57 -0500
Branch: REL9_5_STABLE [210564a74] 2020-11-10 22:51:58 -0500
-->
     <para>
      Fix miscalculation of timeouts
      in <filename>contrib/pg_prewarm</filename>
      and <filename>contrib/postgres_fdw</filename>
      (Alexey Kondratov, Tom Lane)
     </para>

     <para>
      The main loop in <filename>contrib/pg_prewarm</filename>'s
      autoprewarm parent process underestimated its desired sleep time by
      a factor of 1000, causing it to consume much more CPU than intended.
      When waiting for a result from a remote
      server, <filename>contrib/postgres_fdw</filename> overestimated the
      desired timeout by a factor of 1000 (though this error had been
      mitigated by imposing a clamp to 60 seconds).
     </para>

     <para>
      Both of these errors stemmed from incorrectly converting
      seconds-and-microseconds to milliseconds.  Introduce a new
      API <function>TimestampDifferenceMilliseconds()</function>
      to make it easier to get this right in the future.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4823621db] 2021-01-15 11:28:51 -0500
Branch: REL_13_STABLE [f44ae4db5] 2021-01-15 11:29:05 -0500
Branch: REL_12_STABLE [f5d044eae] 2021-01-15 11:29:13 -0500
Branch: REL_11_STABLE [046c8face] 2021-01-15 11:29:18 -0500
Branch: REL_10_STABLE [5fa060c8f] 2021-01-15 11:29:26 -0500
Branch: REL9_6_STABLE [fc6d08b27] 2021-01-15 11:29:34 -0500
Branch: REL9_5_STABLE [3934543c2] 2021-01-15 11:29:43 -0500
Branch: master [9d23c15a0] 2021-01-20 12:07:23 -0500
Branch: REL_13_STABLE [6671e8194] 2021-01-20 12:07:31 -0500
Branch: REL_12_STABLE [561dd8d8a] 2021-01-20 12:07:35 -0500
Branch: REL_11_STABLE [cbcff1729] 2021-01-20 12:07:41 -0500
Branch: REL_10_STABLE [a3345383d] 2021-01-20 12:07:46 -0500
Branch: REL9_6_STABLE [cbcf7b130] 2021-01-20 12:07:52 -0500
Branch: REL9_5_STABLE [175f716a8] 2021-01-20 12:07:57 -0500
-->
     <para>
      Improve <application>configure</application>'s heuristics for
      selecting <varname>PG_SYSROOT</varname> on macOS (Tom Lane)
     </para>

     <para>
      The new method is more likely to produce desirable results when
      Xcode is newer than the underlying operating system.  Choosing
      a sysroot that does not match the OS version may result in
      nonfunctional executables.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [49407dc32] 2020-11-20 00:07:09 -0500
Branch: REL_13_STABLE [9e9a31bd0] 2020-11-20 00:58:26 -0500
Branch: REL_12_STABLE [5b8360427] 2020-11-20 00:58:26 -0500
Branch: REL_11_STABLE [d01e37845] 2020-11-20 00:58:26 -0500
Branch: REL_10_STABLE [153bf8d20] 2020-11-20 00:58:26 -0500
Branch: REL9_6_STABLE [e7abc1111] 2020-11-20 00:58:26 -0500
Branch: REL9_5_STABLE [2bb8c0f1d] 2020-11-20 00:58:26 -0500
-->
     <para>
      While building on macOS, specify <option>-isysroot</option> in
      link steps as well as compile steps (James Hilliard)
     </para>

     <para>
      This likewise improves the results when Xcode is out of sync with
      the operating system.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [9543f0861] 2020-12-07 19:34:13 -0800
Branch: REL_13_STABLE [4f64daf73] 2020-12-07 18:32:56 -0800
Branch: REL_12_STABLE [b07490b91] 2020-12-07 18:39:32 -0800
Branch: REL_11_STABLE [f4f924b3e] 2020-12-07 18:40:27 -0800
Branch: master [6c57f2ed1] 2020-11-09 20:01:33 -0800
Branch: REL_13_STABLE [6a192c77d] 2020-12-07 18:32:32 -0800
Branch: REL_12_STABLE [fa7a52fb9] 2020-12-07 18:39:32 -0800
Branch: REL_11_STABLE [90eb343ef] 2020-12-07 18:40:27 -0800
-->
     <para>
      Fix JIT compilation to be compatible with LLVM 11 and LLVM 12
      (Andres Freund)
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [5da871bfa] 2020-12-07 19:34:13 -0800
Branch: REL_13_STABLE [01c6370a3] 2020-12-07 18:33:03 -0800
Branch: REL_12_STABLE [27b57f806] 2020-12-07 18:39:32 -0800
Branch: REL_11_STABLE [1e16ad101] 2020-12-07 18:40:27 -0800
-->
     <para>
      Fix potential mishandling of references to boolean variables in
      JIT expression compilation (Andres Freund)
     </para>

     <para>
      No field reports attributable to this have been seen, but it seems
      likely that it could cause problems on some architectures.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ad84ecc98] 2020-11-16 15:16:39 -0500
Branch: REL_13_STABLE [53c7b4f62] 2020-11-16 15:16:39 -0500
Branch: REL_12_STABLE [029fa664e] 2020-11-16 15:16:39 -0500
Branch: REL_11_STABLE [89aa30a17] 2020-11-16 15:16:39 -0500
-->
     <para>
      Fix compile failure with ICU 68 and later (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [677f74e5b] 2020-12-01 11:46:56 -0300
Branch: REL_13_STABLE [5a1d1b954] 2020-12-01 11:46:56 -0300
Branch: REL_12_STABLE [f0ff52f25] 2020-12-01 11:46:56 -0300
Branch: REL_11_STABLE [49aaabdf8] 2020-12-01 11:46:56 -0300
-->
     <para>
      Avoid <function>memcpy()</function> with a NULL source pointer and
      zero count during partitioned index creation (&Aacute;lvaro Herrera)
     </para>

     <para>
      While such a call is not known to cause problems in itself, some
      compilers assume that the arguments of <function>memcpy()</function>
      are never NULL, which could result in incorrect optimization of
      nearby code.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c7edf4ac2] 2021-01-24 16:29:47 -0500
Branch: REL_13_STABLE [58a545344] 2021-01-24 16:29:47 -0500
Branch: REL_12_STABLE [5db6ba303] 2021-01-24 16:29:47 -0500
Branch: REL_11_STABLE [c82c015b5] 2021-01-24 16:29:47 -0500
Branch: REL_10_STABLE [728971d5f] 2021-01-24 16:29:48 -0500
Branch: REL9_6_STABLE [7e0786751] 2021-01-24 16:29:48 -0500
Branch: REL9_5_STABLE [c26a0865d] 2021-01-24 16:29:48 -0500
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2021a for DST law changes in Russia (Volgograd zone) and
      South Sudan, plus historical corrections for Australia, Bahamas,
      Belize, Bermuda, Ghana, Israel, Kenya, Nigeria, Palestine,
      Seychelles, and Vanuatu.
     </para>

     <para>
      Notably, the Australia/Currie zone has been corrected to the point
      where it is identical to Australia/Hobart.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13-1">
  <title>Release 13.1</title>

  <formalpara>
  <title>Release date:</title>
  <para>2020-11-12</para>
  </formalpara>

  <para>
   This release contains a variety of fixes from 13.0.
   For information about new features in major release 13, see
   <xref linkend="release-13"/>.
  </para>

  <sect2>
   <title>Migration to Version 13.1</title>

   <para>
    A dump/restore is not required for those running 13.X.
   </para>
  </sect2>

  <sect2>
   <title>Changes</title>

   <itemizedlist>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [0c3185e96] 2020-11-09 07:32:09 -0800
Branch: REL_13_STABLE [c90c84b3f] 2020-11-09 07:32:12 -0800
Branch: REL_12_STABLE [ac8f6243c] 2020-11-09 07:32:12 -0800
Branch: REL_11_STABLE [43ebfea5a] 2020-11-09 07:32:13 -0800
Branch: REL_10_STABLE [f97ecea1e] 2020-11-09 07:32:13 -0800
Branch: REL9_6_STABLE [ff3de4c21] 2020-11-09 07:32:13 -0800
Branch: REL9_5_STABLE [aefc625de] 2020-11-09 07:32:14 -0800
-->
     <para>
      Block <command>DECLARE CURSOR ... WITH HOLD</command> and firing of
      deferred triggers within index expressions and materialized view
      queries (Noah Misch)
     </para>

     <para>
      This is essentially a leak in the <quote>security restricted
      operation</quote> sandbox mechanism.  An attacker having permission
      to create non-temporary SQL objects could parlay this leak to
      execute arbitrary SQL code as a superuser.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Etienne Stalmans for reporting this problem.
      (CVE-2020-25695)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a45bc8a4f] 2020-09-24 18:19:38 -0400
Branch: REL_13_STABLE [cb8885ac4] 2020-09-24 18:19:38 -0400
Branch: REL_12_STABLE [fb93f784f] 2020-09-24 18:19:38 -0400
Branch: REL_11_STABLE [1738a61c8] 2020-09-24 18:19:39 -0400
Branch: REL_10_STABLE [1888ff8d0] 2020-09-24 18:19:39 -0400
Branch: REL9_6_STABLE [7c154f2fd] 2020-09-24 18:19:39 -0400
Branch: REL9_5_STABLE [56b46d3a1] 2020-09-24 18:19:39 -0400
Branch: master [8e5793ab6] 2020-10-19 19:03:46 -0400
Branch: REL_13_STABLE [1814f915b] 2020-10-19 19:03:46 -0400
Branch: REL_12_STABLE [c6d0b9b16] 2020-10-19 19:03:46 -0400
Branch: REL_11_STABLE [5a9f99bed] 2020-10-19 19:03:47 -0400
Branch: REL_10_STABLE [68f236993] 2020-10-19 19:03:47 -0400
Branch: REL9_6_STABLE [5c78f7977] 2020-10-19 19:03:47 -0400
Branch: REL9_5_STABLE [da129a04a] 2020-10-19 19:03:47 -0400
-->
     <para>
      Fix usage of complex connection-string parameters
      in <application>pg_dump</application>,
      <application>pg_restore</application>,
      <application>clusterdb</application>,
      <application>reindexdb</application>,
      and <application>vacuumdb</application> (Tom Lane)
     </para>

     <para>
      The <option>-d</option> parameter
      of <application>pg_dump</application>
      and <application>pg_restore</application>, or
      the <option>--maintenance-db</option> parameter of the other
      programs mentioned, can be a <quote>connection string</quote>
      containing multiple connection parameters rather than just a
      database name.  In cases where these programs need to initiate
      additional connections, such as parallel processing or processing of
      multiple databases, the connection string was forgotten and just the
      basic connection parameters (database name, host, port, and
      username) were used for the additional connections.  This could lead
      to connection failures if the connection string included any other
      essential information, such as non-default SSL or GSS parameters.
      Worse, the connection might succeed but not be encrypted as
      intended, or be vulnerable to man-in-the-middle attacks that the
      intended connection parameters would have prevented.
      (CVE-2020-25694)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [85c54287a] 2020-10-21 16:19:00 -0400
Branch: REL_13_STABLE [2e4af4110] 2020-10-21 16:19:00 -0400
Branch: REL_12_STABLE [f656517ec] 2020-10-21 16:19:01 -0400
Branch: REL_11_STABLE [20be76d5c] 2020-10-21 16:19:01 -0400
Branch: REL_10_STABLE [8175da6e7] 2020-10-21 16:19:02 -0400
Branch: REL9_6_STABLE [870a23230] 2020-10-21 16:18:41 -0400
Branch: REL9_5_STABLE [6997da09a] 2020-10-21 16:18:41 -0400
-->
     <para>
      When <application>psql</application>'s <command>\connect</command>
      command re-uses connection parameters, ensure that all
      non-overridden parameters from a previous connection string are
      re-used (Tom Lane)
     </para>

     <para>
      This avoids cases where reconnection might fail due to omission of
      relevant parameters, such as non-default SSL or GSS options.
      Worse, the reconnection might succeed but not be encrypted as
      intended, or be vulnerable to man-in-the-middle attacks that the
      intended connection parameters would have prevented.
      This is largely the same problem as just cited
      for <application>pg_dump</application> et al,
      although <application>psql</application>'s behavior is more complex
      since the user may intentionally override some connection
      parameters.
      (CVE-2020-25694)
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [098fb0079] 2020-11-09 07:32:09 -0800
Branch: REL_13_STABLE [67029845b] 2020-11-09 07:32:12 -0800
Branch: REL_12_STABLE [3855e5b47] 2020-11-09 07:32:13 -0800
Branch: REL_11_STABLE [7b356c78f] 2020-11-09 07:32:13 -0800
Branch: REL_10_STABLE [a498db87b] 2020-11-09 07:32:13 -0800
Branch: REL9_6_STABLE [12fd81cb7] 2020-11-09 07:32:14 -0800
Branch: REL9_5_STABLE [a54dfbee1] 2020-11-09 07:32:14 -0800
-->
     <para>
      Prevent <application>psql</application>'s <command>\gset</command>
      command from modifying specially-treated variables (Noah Misch)
     </para>

     <para>
      <command>\gset</command> without a prefix would overwrite whatever
      variables the server told it to.  Thus, a compromised server could
      set specially-treated variables such as <varname>PROMPT1</varname>,
      giving the ability to execute arbitrary shell code in the user's
      session.
     </para>

     <para>
      The <productname>PostgreSQL</productname> Project thanks
      Nick Cleaton for reporting this problem.
      (CVE-2020-25696)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [4e9821b6f] 2020-10-14 20:12:26 -0300
Branch: REL_13_STABLE [72e43fc31] 2020-10-14 20:12:26 -0300
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [7f4708818] 2020-10-15 09:48:36 -0300
Branch: REL_13_STABLE [9f783aea6] 2020-10-15 09:52:35 -0300
-->
     <para>
      Fix unintended breakage of the replication protocol
      (&Aacute;lvaro Herrera)
     </para>

     <para>
      A walsender reports two command-completion events
      for <literal>START_REPLICATION</literal>.  This was undocumented and
      apparently unintentional; so we failed to notice that a late 13.0
      change removed the duplicate event.  However it turns out that
      walreceivers require the extra event in some code paths.  The most
      practical fix is to decree that the extra event is part of the
      protocol and resume generating it.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [aca74843e] 2020-09-24 10:39:52 +1200
Branch: REL_13_STABLE [052014a20] 2020-09-24 10:27:22 +1200
Branch: REL_12_STABLE [7664cc869] 2020-09-24 10:30:47 +1200
Branch: REL_11_STABLE [c5a5bd0bb] 2020-09-24 10:31:57 +1200
Branch: REL_10_STABLE [dd36d6b00] 2020-09-24 10:33:00 +1200
Branch: REL9_6_STABLE [d38e15979] 2020-09-24 10:35:10 +1200
Branch: REL9_5_STABLE [23d8b3577] 2020-09-24 10:36:27 +1200
-->
     <para>
      Ensure that SLRU directories are properly fsync'd during checkpoints
      (Thomas Munro)
     </para>

     <para>
      This prevents possible data loss in a subsequent operating system
      crash.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d907bd054] 2020-11-03 15:41:32 -0500
Branch: REL_13_STABLE [768dbef0d] 2020-11-03 15:41:32 -0500
Branch: REL_12_STABLE [136f87ea5] 2020-11-03 15:41:32 -0500
Branch: REL_11_STABLE [501035a0a] 2020-11-03 15:41:32 -0500
Branch: REL_10_STABLE [df4405b78] 2020-11-03 15:41:32 -0500
Branch: REL9_6_STABLE [04c4b495b] 2020-11-03 15:41:32 -0500
Branch: REL9_5_STABLE [77df80cf6] 2020-11-03 15:41:32 -0500
-->
     <para>
      Fix <command>ALTER ROLE</command> for users with
      the <literal>BYPASSRLS</literal> attribute (Tom Lane, Stephen Frost)
     </para>

     <para>
      The <literal>BYPASSRLS</literal> attribute is only allowed to be
      changed by superusers, but other <command>ALTER ROLE</command>
      operations, such as password changes, should be allowed with only
      ordinary permission checks.  The previous coding erroneously
      restricted all changes on such a role to superusers.
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [bf797a8d9] 2020-11-03 15:28:23 +0100
Branch: REL_13_STABLE [539775981] 2020-11-03 15:28:36 +0100
-->
     <para>
      Disallow <command>ALTER TABLE ONLY ... DROP EXPRESSION</command> when
      there are child tables (Peter Eisentraut)
     </para>

     <para>
      The current implementation cannot handle this case correctly, so just
      forbid it for now.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [bbb927b4d] 2020-10-20 19:22:09 -0300
Branch: REL_13_STABLE [5f6463a20] 2020-10-20 19:22:09 -0300
Branch: REL_12_STABLE [0e6b6f8c7] 2020-10-20 19:22:09 -0300
Branch: REL_11_STABLE [a795f6782] 2020-10-20 19:22:09 -0300
-->
     <para>
      Ensure that <command>ALTER TABLE ONLY ... ENABLE/DISABLE
      TRIGGER</command> does not recurse to child tables
      (&Aacute;lvaro Herrera)
     </para>

     <para>
      Previously the <literal>ONLY</literal> flag was ignored.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5b7bfc397] 2020-11-05 11:44:32 -0500
Branch: REL_13_STABLE [44b973b91] 2020-11-05 11:44:32 -0500
Branch: REL_12_STABLE [0bdf1ef3d] 2020-11-05 11:44:32 -0500
Branch: REL_11_STABLE [7dc18c619] 2020-11-05 11:44:32 -0500
-->
     <para>
      Allow <command>LOCK TABLE</command> to succeed on a self-referential
      view (Tom Lane)
     </para>

     <para>
      It previously threw an error complaining about infinite recursion,
      but there seems no need to disallow the case.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [b17ff07aa] 2020-11-01 21:22:07 +0900
Branch: REL_13_STABLE [bb62df46b] 2020-11-01 21:24:10 +0900
Branch: REL_12_STABLE [41a033b50] 2020-11-01 21:24:15 +0900
-->
     <para>
      Retain statistics about an index across <command>REINDEX
      CONCURRENTLY</command> (Michael Paquier, Fabr&iacute;zio de Royes Mello)
     </para>

     <para>
      Non-concurrent reindexing has always preserved such statistics.
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [e66bcfb4c] 2020-09-29 14:15:57 +0900
Branch: REL_13_STABLE [1aedaba78] 2020-09-29 14:16:12 +0900
Branch: REL_12_STABLE [8aa4496dd] 2020-09-29 14:16:18 +0900
-->
     <para>
      Fix incorrect progress reporting from <command>REINDEX
      CONCURRENTLY</command> (Matthias van de Meent, Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ad77039fa] 2020-10-28 13:47:02 -0400
Branch: REL_13_STABLE [70492195b] 2020-10-28 13:47:02 -0400
Branch: REL_12_STABLE [43330cdd4] 2020-10-28 13:47:02 -0400
-->
     <para>
      Ensure that <literal>GENERATED</literal> columns are updated when
      the column(s) they depend on are updated via a rule or an updatable
      view (Tom Lane)
     </para>

     <para>
      This fix also takes care of possible failure to fire a
      column-specific trigger in such cases.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [72647ac3b] 2020-09-28 14:12:38 -0400
Branch: REL_13_STABLE [61a78c71a] 2020-09-28 14:12:38 -0400
Branch: REL_12_STABLE [29f20db85] 2020-09-28 14:12:38 -0400
-->
     <para>
      Fix failures with collation-dependent partition bound expressions
      (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [560564d3a] 2020-11-04 12:46:28 +0100
Branch: REL_13_STABLE [82d4a2a7d] 2020-11-04 12:46:38 +0100
Branch: REL_12_STABLE [ea9087938] 2020-11-04 12:46:52 +0100
-->
     <para>
      Support hashing of text arrays (Peter Eisentraut)
     </para>

     <para>
      Array hashing failed if the array element type is collatable.
      Notably, this prevented using hash partitioning with a text array
      column as partition key.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3db322eaa] 2020-10-07 17:10:26 -0400
Branch: REL_13_STABLE [5ed20a689] 2020-10-07 17:10:26 -0400
-->
     <para>
      Prevent internal overflows in cross-type datetime
      comparisons (Nikita Glukhov, Alexander Korotkov, Tom Lane)
     </para>

     <para>
      Previously, comparing a date to a timestamp would fail if the date
      is past the valid range for timestamps.  There were also corner
      cases involving overflow of close-to-the-limit timestamp values
      during timezone rotation.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [489c9c340] 2020-09-30 15:40:23 -0400
Branch: REL_13_STABLE [99fd38c02] 2020-09-30 15:40:23 -0400
Branch: REL_12_STABLE [c5232dca8] 2020-09-30 15:40:23 -0400
Branch: REL_11_STABLE [b0fe0b022] 2020-09-30 15:40:23 -0400
Branch: REL_10_STABLE [db96be24c] 2020-09-30 15:40:23 -0400
Branch: REL9_6_STABLE [19e798268] 2020-09-30 15:40:23 -0400
Branch: REL9_5_STABLE [4857e6fe1] 2020-09-30 15:40:23 -0400
-->
     <para>
      Fix off-by-one conversion of negative years to BC dates
      in <function>to_date()</function>
      and <function>to_timestamp()</function> (Dar Alathar-Yemen, Tom Lane)
     </para>

     <para>
      Also, arrange for the combination of a negative year and an
      explicit <quote>BC</quote> marker to cancel out and produce AD.
     </para>
    </listitem>

    <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [c2aa562ea] 2020-09-29 11:00:22 +0300
Branch: REL_13_STABLE [abcc0ab16] 2020-09-29 11:55:15 +0300
Branch: master [927d9abb6] 2020-09-29 12:00:04 +0300
Branch: REL_13_STABLE [651bdbc81] 2020-09-29 12:00:12 +0300
-->
     <para>
      Allow the <type>jsonpath</type> <function>.datetime()</function>
      method to accept ISO 8601-format timestamps (Nikita Glukhov)
     </para>

     <para>
      This is not required by SQL, but it seems appropriate since
      our <function>to_json()</function> functions generate that timestamp
      format for Javascript compatibility.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [fd26f7823] 2020-09-29 16:21:46 +0900
Branch: REL_13_STABLE [059caf36c] 2020-09-29 16:23:57 +0900
Branch: REL_12_STABLE [4d342b9d4] 2020-09-29 16:24:20 +0900
Branch: REL_11_STABLE [462ff7966] 2020-09-29 16:24:47 +0900
Branch: REL_10_STABLE [334417538] 2020-09-29 16:25:08 +0900
Branch: REL9_6_STABLE [7be02a3bf] 2020-09-29 16:25:20 +0900
Branch: REL9_5_STABLE [40a8fb1e0] 2020-09-29 16:25:51 +0900
-->
     <para>
      Ensure that standby servers will archive WAL timeline history files
      when <varname>archive_mode</varname> is set
      to <literal>always</literal> (Grigory Smolkin, Fujii Masao)
     </para>

     <para>
      This oversight could lead to failure of subsequent PITR recovery
      attempts.
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [b94109ce3] 2020-10-15 11:41:58 +1300
Branch: REL_13_STABLE [e0950135a] 2020-10-15 11:42:17 +1300
Branch: master [70516a178] 2020-10-15 18:34:21 +1300
Branch: REL_13_STABLE [47522ee00] 2020-10-15 18:38:03 +1300
-->
     <para>
      Fix edge cases in detecting premature death of the postmaster on
      platforms that use <function>kqueue()</function> (Thomas Munro)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [ebb7ae839] 2020-11-03 22:31:57 +0100
Branch: REL_13_STABLE [2d26c4ac7] 2020-11-03 22:32:34 +0100
-->
     <para>
      Avoid generating an incorrect incremental-sort plan when the sort key
      is a volatile expression (James Coleman)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d7885b1f8] 2020-10-06 11:43:53 -0400
Branch: REL_13_STABLE [b7f166efa] 2020-10-06 11:43:53 -0400
Branch: REL_12_STABLE [3d69efc4f] 2020-10-06 11:43:54 -0400
-->
     <para>
      Fix possible crash when considering partition-wise joins
      during GEQO planning (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [dfc797730] 2020-11-01 18:38:42 -0500
Branch: REL_13_STABLE [2330f4d3a] 2020-11-01 18:38:42 -0500
Branch: master [fd2997565] 2020-11-02 11:25:18 -0500
Branch: REL_13_STABLE [7957e75c5] 2020-11-02 11:25:18 -0500
-->
     <para>
      Fix possible infinite loop or corrupted output data in TOAST
      decompression (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
Branch: master [48e129134] 2020-11-04 18:42:27 -0800
Branch: REL_13_STABLE [02c9386ca] 2020-11-04 18:42:24 -0800
-->
     <para>
      Fix counting of the number of entries in B-tree indexes during
      cleanup-only <command>VACUUM</command>s (Peter Geoghegan)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [7577dd848] 2020-11-07 00:39:19 +0100
Branch: REL_13_STABLE [6a7b55f37] 2020-11-07 00:40:06 +0100
Branch: REL_12_STABLE [8149e9f9a] 2020-11-07 00:40:40 +0100
Branch: REL_11_STABLE [895d0f0e8] 2020-11-07 00:41:02 +0100
Branch: REL_10_STABLE [0b96fc977] 2020-11-07 00:41:19 +0100
Branch: REL9_6_STABLE [bae31e75f] 2020-11-07 00:41:36 +0100
Branch: REL9_5_STABLE [d2d3a4bd3] 2020-11-07 00:41:52 +0100
-->
     <para>
      Ensure that data is detoasted before being inserted into a BRIN
      index (Tomas Vondra)
     </para>

     <para>
      Index entries are not supposed to contain out-of-line TOAST
      pointers, but BRIN didn't get that memo.  This could lead to errors
      like <quote>missing chunk number 0 for toast value NNN</quote>.
      (If you are faced with such an error from an existing
      index, <command>REINDEX</command> should be enough to fix it.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [371668a83] 2020-10-12 18:01:34 -0400
Branch: REL_13_STABLE [962ab473e] 2020-10-12 18:01:34 -0400
Branch: REL_12_STABLE [12945874e] 2020-10-12 18:01:34 -0400
-->
     <para>
      Fix buffered GiST index builds to work when the index has included
      columns (Pavel Borisov)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0a4b34031] 2020-11-02 21:11:50 -0500
Branch: REL_13_STABLE [a58a631b4] 2020-11-02 21:11:50 -0500
Branch: REL_12_STABLE [d3befe9b9] 2020-11-02 21:11:50 -0500
Branch: REL_11_STABLE [f28b089cb] 2020-11-02 21:11:50 -0500
Branch: REL_10_STABLE [7827497ba] 2020-11-02 21:11:50 -0500
-->
     <para>
      Fix unportable use of <function>getnameinfo()</function>
      in <structname>pg_hba_file_rules</structname> view (Tom Lane)
     </para>

     <para>
      On FreeBSD 11, and possibly other platforms, the
      view's <structfield>address</structfield>
      and <structfield>netmask</structfield> columns were always null due
      to this error.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [f90e80b91] 2020-10-31 08:43:28 -0700
Branch: REL_13_STABLE [ab2e2ce46] 2020-10-31 08:43:32 -0700
Branch: REL_12_STABLE [741b84e9f] 2020-10-31 08:44:13 -0700
Branch: REL_11_STABLE [045466675] 2020-10-31 08:45:19 -0700
-->
     <para>
      Avoid crash if <varname>debug_query_string</varname> is NULL
      when starting a parallel worker (Noah Misch)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ba9f18abd] 2020-10-25 13:57:46 -0400
Branch: REL_13_STABLE [d88d8ad28] 2020-10-25 13:57:46 -0400
Branch: REL_12_STABLE [de78c1007] 2020-10-25 13:57:46 -0400
Branch: master [20d3fe900] 2020-10-26 11:36:53 -0400
Branch: master [8b39345a9] 2020-11-08 13:08:36 -0500
Branch: REL_13_STABLE [7aeb6404f] 2020-11-08 13:08:36 -0500
Branch: REL_12_STABLE [94ec005f3] 2020-11-08 13:08:36 -0500
-->
     <para>
      Avoid failures when a <literal>BEFORE ROW UPDATE</literal> trigger
      returns the <quote>old</quote> row of a table having dropped
      or <quote>missing</quote> columns (Amit Langote, Tom Lane)
     </para>

     <para>
      This method of suppressing an update could result in crashes,
      unexpected <literal>CHECK</literal> constraint failures, or
      incorrect <literal>RETURNING</literal> output,
      because <quote>missing</quote> columns would read as NULLs for those
      purposes.  (A column is <quote>missing</quote> for this purpose if
      it was added by <command>ALTER TABLE ADD COLUMN</command> with a
      non-NULL, but constant, default value.)  Dropped columns could cause
      trouble as well.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [87a174c0e] 2020-10-23 11:32:33 -0400
Branch: REL_13_STABLE [e4538708d] 2020-10-23 11:32:33 -0400
-->
     <para>
      Fix <command>EXPLAIN</command>'s output for incremental sort plans
      to have correct tag nesting in XML output mode (Daniel Gustafsson)
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: REL_13_STABLE [1f53d0b9f] 2020-10-20 14:09:16 +0200
Branch: REL_12_STABLE [bd0677bb8] 2020-10-20 14:31:52 +0200
Branch: REL_11_STABLE [6e03a8a30] 2020-10-20 14:50:43 +0200
Branch: REL_10_STABLE [f78ebbe68] 2020-10-20 15:19:47 +0200
Branch: REL9_6_STABLE [d4e654d15] 2020-10-20 15:35:31 +0200
Branch: REL9_5_STABLE [d27c18d26] 2020-10-20 17:22:41 +0200
-->
     <para>
      Avoid unnecessary failure when transferring very large payloads
      through shared memory queues (Markus Wanner)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c8ab97017] 2020-10-19 14:33:09 -0400
Branch: REL_13_STABLE [25378db74] 2020-10-19 14:33:10 -0400
-->
     <para>
      Fix omission of result data type coercion in some cases in
      SQL-language functions (Tom Lane)
     </para>

     <para>
      This could lead to wrong results or crashes, depending on the data
      types involved.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [72559438f] 2020-10-15 14:29:53 -0700
Branch: REL_13_STABLE [ae3e75aba] 2020-10-15 14:30:40 -0700
Branch: REL_12_STABLE [c8a2bb0f1] 2020-10-15 14:31:32 -0700
Branch: REL_11_STABLE [f3dee5b9a] 2020-10-15 15:06:16 -0700
Branch: master [fe2a16d8b] 2020-10-15 18:17:00 -0700
Branch: REL_13_STABLE [efc9a8e98] 2020-10-15 18:17:00 -0700
Branch: REL_12_STABLE [c835c7ffe] 2020-10-15 18:17:01 -0700
Branch: REL_11_STABLE [4a4f4487d] 2020-10-15 18:17:01 -0700
-->
     <para>
      Fix incorrect handling of template function attributes in JIT code
      generation (Andres Freund)
     </para>

     <para>
      This has been shown to cause crashes on <literal>s390x</literal>,
      and very possibly there are other cases on other platforms.
     </para>
    </listitem>

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [f5c1167b1] 2020-10-11 21:31:37 -0700
Branch: REL_13_STABLE [d41cb63ff] 2020-10-11 21:31:40 -0700
Branch: master [88ea7a118] 2020-10-11 21:31:37 -0700
Branch: REL_13_STABLE [5efa788e1] 2020-10-11 21:31:40 -0700
-->
     <para>
      Improve code generated for compare_exchange and fetch_add operations
      on PPC (Noah Misch)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e55f718fc] 2020-09-26 16:04:06 -0400
Branch: REL_13_STABLE [f7873900f] 2020-09-26 16:04:06 -0400
Branch: REL_12_STABLE [bda32733c] 2020-09-26 16:04:06 -0400
Branch: REL_11_STABLE [dd89ba578] 2020-09-26 16:04:06 -0400
Branch: REL_10_STABLE [de6725deb] 2020-09-26 16:04:06 -0400
Branch: REL9_6_STABLE [acab757ce] 2020-09-26 16:04:06 -0400
Branch: REL9_5_STABLE [bf34ae930] 2020-09-26 16:04:06 -0400
-->
     <para>
      Fix relation cache memory leaks with RLS policies (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [623644f02] 2020-11-06 22:52:16 -0300
Branch: REL_13_STABLE [d94d37f8c] 2020-11-06 22:52:15 -0300
Branch: REL_12_STABLE [8ad6a0c1b] 2020-11-06 22:52:15 -0300
-->
     <para>
      Fix edge-case memory leak
      in <function>index_get_partition()</function> (Justin Pryzby)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [397ea901e] 2020-10-12 13:31:24 -0400
Branch: REL_13_STABLE [9343bfefa] 2020-10-12 13:31:24 -0400
Branch: REL_12_STABLE [f35c11770] 2020-10-12 13:31:24 -0400
Branch: REL_11_STABLE [cfa4cff30] 2020-10-12 13:31:24 -0400
Branch: REL_10_STABLE [a5c77e6b8] 2020-10-12 13:31:24 -0400
Branch: REL9_6_STABLE [c7573ab1e] 2020-10-12 13:31:24 -0400
Branch: REL9_5_STABLE [43ca5e07d] 2020-10-12 13:31:24 -0400
-->
     <para>
      Fix small memory leak when SIGHUP processing decides that a new GUC
      variable value cannot be applied without a restart (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a6b1f5365] 2020-09-29 11:18:30 -0400
Branch: REL_13_STABLE [f0e4ec74e] 2020-09-29 11:18:30 -0400
Branch: REL_12_STABLE [c1e044bb3] 2020-09-29 11:18:31 -0400
Branch: REL_11_STABLE [13a1901ba] 2020-09-29 11:18:31 -0400
-->
     <para>
      Fix memory leaks
      in <application>PL/pgsql</application>'s <command>CALL</command>
      processing (Pavel Stehule, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [7d00a6b2d] 2020-10-17 16:53:48 -0400
Branch: REL_13_STABLE [d2074daeb] 2020-10-19 11:23:51 -0400
Branch: REL_12_STABLE [407580aab] 2020-10-19 11:23:51 -0400
Branch: REL_11_STABLE [883226441] 2020-10-19 11:23:52 -0400
Branch: REL_10_STABLE [6670e9107] 2020-10-19 11:23:52 -0400
Branch: REL9_6_STABLE [cdc7ace16] 2020-10-19 11:23:52 -0400
Branch: REL9_5_STABLE [6acc31a20] 2020-10-19 11:23:52 -0400
-->
     <para>
      In <application>libpq</application> for Windows,
      call <function>WSAStartup()</function> once per process
      and <function>WSACleanup()</function> not at all (Tom Lane,
      Alexander Lakhin)
     </para>

     <para>
      Previously, <application>libpq</application>
      invoked <function>WSAStartup()</function> at connection start
      and <function>WSACleanup()</function> at connection cleanup.
      However, it appears that calling <function>WSACleanup()</function>
      can interfere with other program operations; notably, we have
      observed rare failures to emit expected output to stdout.  There
      appear to be no ill effects from omitting the call, so do that.
      (This also eliminates a performance issue from repeated DLL loads and
      unloads when a program performs a series of database connections.)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [21d36747d] 2020-10-24 13:12:08 -0400
Branch: REL_13_STABLE [fd048e0cb] 2020-10-24 13:12:19 -0400
Branch: REL_12_STABLE [bdc79ddd1] 2020-10-24 13:12:26 -0400
Branch: REL_11_STABLE [12a73f29f] 2020-10-24 13:12:31 -0400
Branch: REL_10_STABLE [f38b66ec0] 2020-10-24 13:12:41 -0400
Branch: REL9_6_STABLE [379c43bda] 2020-10-24 13:12:47 -0400
Branch: REL9_5_STABLE [758b45e83] 2020-10-24 13:12:53 -0400
-->
     <para>
      Fix <application>ecpg</application> library's per-thread
      initialization logic for Windows (Tom Lane, Alexander Lakhin)
     </para>

     <para>
      Multi-threaded <application>ecpg</application> applications could
      suffer rare misbehavior due to incorrect locking.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [1e3868ab3] 2020-11-07 15:03:44 -0500
Branch: REL_13_STABLE [1bccb159a] 2020-11-07 15:03:44 -0500
Branch: master [eed4356fa] 2020-11-07 16:25:42 -0500
Branch: REL_13_STABLE [3459f4169] 2020-11-07 16:25:42 -0500
-->
     <para>
      Fix <application>ecpg</application>'s mis-processing
      of <literal>B'...'</literal> and <literal>X'...'</literal> literals
      (Shenhao Wang)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [66f8687a8] 2020-10-28 14:35:53 -0400
Branch: REL_13_STABLE [ba4f5413e] 2020-10-28 14:35:53 -0400
Branch: REL_12_STABLE [cb0982ba9] 2020-10-28 14:35:53 -0400
Branch: REL_11_STABLE [9eb250339] 2020-10-28 14:35:53 -0400
Branch: REL_10_STABLE [504f963f7] 2020-10-28 14:35:53 -0400
Branch: REL9_6_STABLE [204d77969] 2020-10-28 14:35:53 -0400
Branch: REL9_5_STABLE [aff06436c] 2020-10-28 14:35:53 -0400
-->
     <para>
      On Windows, make <application>psql</application> read the output of
      a backtick command in text mode, not binary mode (Tom Lane)
     </para>

     <para>
      This ensures proper handling of newlines.
     </para>
    </listitem>

    <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [3eb3d3e78] 2020-09-04 13:54:54 -0400
Branch: REL_13_STABLE Release: REL_13_0 [72857482c] 2020-09-04 13:55:11 -0400
Branch: REL_12_STABLE [616110eac] 2020-09-04 13:55:03 -0400
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9e5f1f21a] 2020-10-07 12:51:02 -0400
Branch: REL_13_STABLE [2ea624b4b] 2020-10-07 12:51:03 -0400
Branch: REL_12_STABLE [d8c2a2199] 2020-10-07 12:51:04 -0400
Branch: REL_11_STABLE [f2c6e94f0] 2020-10-07 12:51:05 -0400
Branch: REL_10_STABLE [0c79dcb36] 2020-10-07 12:51:05 -0400
Branch: REL9_6_STABLE [710c0a66d] 2020-10-07 12:51:06 -0400
Branch: REL9_5_STABLE [0bfe356c5] 2020-10-07 12:51:06 -0400
-->
     <para>
      Ensure that <application>pg_dump</application> collects per-column
      information about extension configuration tables (Fabr&iacute;zio de
      Royes Mello, Tom Lane)
     </para>

     <para>
      Failure to do this led to crashes when
      specifying <option>--inserts</option>, or underspecified (though
      usually correct) <command>COPY</command> commands when
      using <command>COPY</command> to reload the tables' data.
     </para>
    </listitem>

    <listitem>
<!--
Author: Bruce Momjian <bruce@momjian.us>
Branch: master [3c0471b5f] 2020-10-15 19:33:46 -0400
Branch: REL_13_STABLE [59cfff65b] 2020-10-15 19:33:45 -0400
Branch: REL_12_STABLE [a106236d8] 2020-10-15 19:33:43 -0400
Branch: REL_11_STABLE [eb421c83b] 2020-10-15 19:33:42 -0400
Branch: REL_10_STABLE [85fedf39f] 2020-10-15 19:33:36 -0400
Branch: REL9_6_STABLE [39c23c199] 2020-10-15 19:33:36 -0400
Branch: REL9_5_STABLE [d9ae2297b] 2020-10-15 19:33:36 -0400
Branch: master [536de14e2] 2020-10-15 20:37:20 -0400
Branch: REL_13_STABLE [79fe23465] 2020-10-15 20:37:20 -0400
Branch: REL_12_STABLE [0ab7ca98a] 2020-10-15 20:37:20 -0400
Branch: REL_11_STABLE [16be4e435] 2020-10-15 20:37:19 -0400
Branch: REL_10_STABLE [6e34cc8ab] 2020-10-15 20:37:19 -0400
Branch: REL9_6_STABLE [9dcffe69a] 2020-10-15 20:37:19 -0400
Branch: REL9_5_STABLE [b05672c72] 2020-10-15 20:37:19 -0400
-->
     <para>
      Make <application>pg_upgrade</application> check for pre-existence
      of tablespace directories in the target cluster (Bruce Momjian)
     </para>
    </listitem>

    <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [ca2a12c93] 2020-10-19 09:36:56 +0900
Branch: REL_13_STABLE [1bd9b2b23] 2020-10-19 09:37:50 +0900
Branch: REL_12_STABLE [57bdf29dd] 2020-10-19 09:37:55 +0900
Branch: REL_11_STABLE [914139081] 2020-10-19 09:38:01 +0900
Branch: REL_10_STABLE [e8d36f9ec] 2020-10-19 09:38:06 +0900
Branch: REL9_6_STABLE [994a02f7f] 2020-10-19 09:38:13 +0900
Branch: REL9_5_STABLE [099238322] 2020-10-19 09:38:18 +0900
-->
     <para>
      Fix potential memory leak in <filename>contrib/pgcrypto</filename>
      (Michael Paquier)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [02a75f836] 2020-10-16 11:59:13 -0400
Branch: REL_13_STABLE [3d338a46a] 2020-10-16 11:59:25 -0400
Branch: REL_12_STABLE [7004ce758] 2020-10-16 11:59:31 -0400
Branch: REL_11_STABLE [1eb2d7e3e] 2020-10-16 11:59:36 -0400
Branch: REL_10_STABLE [3e1a4c260] 2020-10-16 11:59:41 -0400
Branch: REL9_6_STABLE [e15115b4d] 2020-10-16 11:59:47 -0400
Branch: REL9_5_STABLE [9c3032881] 2020-10-16 11:59:52 -0400
-->
     <para>
      Add check for an unlikely failure case
      in <filename>contrib/pgcrypto</filename> (Daniel Gustafsson)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [4a071afbd] 2020-10-29 15:28:14 -0400
Branch: REL_13_STABLE [ee03baad2] 2020-10-29 15:28:28 -0400
Branch: REL_12_STABLE [25b587f03] 2020-10-29 15:28:35 -0400
Branch: REL_11_STABLE [24d769b90] 2020-10-29 15:28:41 -0400
Branch: REL_10_STABLE [c39f4e81d] 2020-10-29 15:28:47 -0400
-->
     <para>
      Fix recently-added <type>timetz</type> test case so it works when
      the USA is not observing daylight savings time (Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c4a803ac7] 2020-10-16 21:53:33 -0400
Branch: REL_13_STABLE [3f26dca76] 2020-10-16 21:53:43 -0400
Branch: REL_12_STABLE [b39c94097] 2020-10-16 21:53:50 -0400
Branch: REL_11_STABLE [2b9166dbc] 2020-10-16 21:53:55 -0400
Branch: REL_10_STABLE [aae4097b0] 2020-10-16 21:54:03 -0400
Branch: REL9_6_STABLE [13dbf4ab8] 2020-10-16 21:54:09 -0400
Branch: REL9_5_STABLE [c8cb243cb] 2020-10-16 21:54:14 -0400
Branch: master [7d6d6bce4] 2020-10-22 21:23:47 -0400
Branch: REL_13_STABLE [96ed2ae93] 2020-10-22 21:24:01 -0400
Branch: REL_12_STABLE [78ccf7f42] 2020-10-22 21:24:07 -0400
Branch: REL_11_STABLE [02f86d523] 2020-10-22 21:24:12 -0400
Branch: REL_10_STABLE [a357cc05d] 2020-10-22 21:24:17 -0400
Branch: REL9_6_STABLE [05a36321a] 2020-10-22 21:24:23 -0400
Branch: REL9_5_STABLE [0abebb58f] 2020-10-22 21:24:28 -0400
-->
     <para>
      Update time zone data files to <application>tzdata</application>
      release 2020d for DST law changes in Fiji, Morocco, Palestine, the
      Canadian Yukon, Macquarie Island, and Casey Station (Antarctica);
      plus historical corrections for France, Hungary, Monaco, and
      Palestine.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ce0e97f80] 2020-10-16 21:40:16 -0400
Branch: REL_13_STABLE [e0cf5e9b2] 2020-10-16 21:40:16 -0400
Branch: REL_12_STABLE [3d13a8307] 2020-10-16 21:40:16 -0400
Branch: REL_11_STABLE [4a2528bfa] 2020-10-16 21:40:16 -0400
Branch: REL_10_STABLE [41eeeb348] 2020-10-16 21:40:16 -0400
Branch: REL9_6_STABLE [5515c73a6] 2020-10-16 21:40:16 -0400
Branch: REL9_5_STABLE [38fac9c1f] 2020-10-16 21:40:16 -0400
Branch: master [c5054da0d] 2020-10-22 21:15:22 -0400
Branch: REL_13_STABLE [0e551533b] 2020-10-22 21:15:37 -0400
Branch: REL_12_STABLE [f56c42e50] 2020-10-22 21:16:04 -0400
Branch: REL_11_STABLE [d2ffe0a00] 2020-10-22 21:16:16 -0400
Branch: REL_10_STABLE [34285083b] 2020-10-22 21:16:23 -0400
Branch: REL9_6_STABLE [58f9f52a3] 2020-10-22 21:16:31 -0400
Branch: REL9_5_STABLE [ff26f804a] 2020-10-22 21:16:38 -0400
-->
     <para>
      Sync our copy of the timezone library with IANA tzcode release 2020d
      (Tom Lane)
     </para>

     <para>
      This absorbs upstream's change of <application>zic</application>'s
      default output option from <quote>fat</quote>
      to <quote>slim</quote>.  That's just cosmetic for our purposes, as
      we continue to select the <quote>fat</quote> mode in pre-v13
      branches.  This change also ensures
      that <function>strftime()</function> does not
      change <varname>errno</varname> unless it fails.
     </para>
    </listitem>

   </itemizedlist>

  </sect2>
 </sect1>

 <sect1 id="release-13">
  <title>Release 13</title>

  <formalpara>
   <title>Release date:</title>
   <para>2020-09-24</para>
  </formalpara>

  <sect2>
   <title>Overview</title>

   <para>
    <productname>PostgreSQL</productname> 13 contains many new features and
    enhancements, including:
   </para>

   <itemizedlist>
    <listitem>
     <para>
      Space savings and performance gains from de-duplication of B-tree
      index entries
     </para>
    </listitem>
    <listitem>
     <para>
      Improved performance for queries that use aggregates or partitioned
      tables
     </para>
    </listitem>
    <listitem>
     <para>
      Better query planning when using extended statistics
     </para>
    </listitem>
    <listitem>
     <para>
      Parallelized vacuuming of indexes
     </para>
    </listitem>
    <listitem>
     <para>
      Incremental sorting
     </para>
    </listitem>
   </itemizedlist>

   <para>
    The above items and other new features
    of <productname>PostgreSQL</productname> 13 are explained in more
    detail in the sections below.
   </para>

  </sect2>

  <sect2>

  <title>Migration to Version 13</title>

    <para>
     A dump/restore using <xref linkend="app-pg-dumpall"/> or use of <xref
     linkend="pgupgrade"/> or logical replication is required for those
     wishing to migrate data from any previous release.  See <xref
     linkend="upgrading"/> for general information on migrating to new major
     releases.
    </para>

    <para>
     Version 13 contains a number of changes that may affect compatibility
     with previous releases.  Observe the following incompatibilities:
    </para>

   <itemizedlist>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-09-07 [ca70bdaef] Fix issues around strictness of SIMILAR TO.
-->

     <para>
      Change <link linkend="functions-similarto-regexp"><command>SIMILAR
      TO ... ESCAPE NULL</command></link> to return <literal>NULL</literal>
      (Tom Lane)
     </para>

     <para>
      This new behavior matches the <acronym>SQL</acronym> specification.
      Previously a null <literal>ESCAPE</literal> value was taken to mean
      using the default escape string (a backslash character).  This also
      applies to <literal>substring(<replaceable>text</replaceable>
      FROM <replaceable>pattern</replaceable>
      ESCAPE <replaceable>text</replaceable>)</literal>.  The previous
      behavior has been retained in old views by keeping the original
      function unchanged.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-01-31 [870ad6a59] Fix not-quite-right string comparison in parse_jsonb_ind
-->

     <para>
      Make <link
      linkend="textsearch-functions-table"><function>json[b]_to_tsvector()</function></link>
      fully check the spelling of its <literal>string</literal> option
      (Dominik Czarnota)
     </para>
    </listitem>

    <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-03-16 [b09ff5366] Simplify the effective_io_concurrency setting.
-->

     <para>
      Change the way non-default <xref
      linkend="guc-effective-io-concurrency"/> values affect concurrency
      (Thomas Munro)
     </para>

     <para>
      Previously, this value was adjusted before setting the number of
      concurrent requests.  The value is now used directly.  Conversion of
      old values to new ones can be done using:
     </para>

<programlisting>
SELECT round(sum(<replaceable>OLDVALUE</replaceable> / n::float)) AS newvalue FROM generate_series(1, <replaceable>OLDVALUE</replaceable>) s(n);
</programlisting>
    </listitem>

    <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-11-12 [5c46e7d82] pg_stat_{ssl,gssapi}: Show only processes with connectio
-->

     <para>
      Prevent display of auxiliary processes in <xref
      linkend="pg-stat-ssl-view"/> and <xref linkend="pg-stat-gssapi-view"/>
      system views (Euler Taveira)
     </para>

     <para>
      Queries that join these views to <xref
      linkend="pg-stat-activity-view"/> and wish to see auxiliary processes
      will need to use left joins.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-03-19 [1d253bae5] Rename the recovery-related wait events.
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-05-15 [36ac359d3] Rename assorted LWLock tranches.
2020-05-15 [474e7da64] Change locktype "speculative token" to "spectoken".
2020-05-15 [14a910109] Drop the redundant "Lock" suffix from LWLock wait event
2020-05-16 [3048898e7] Mop-up for wait event naming issues.
-->

     <para>
      Rename various <link linkend="wait-event-table">wait
      events</link> to improve consistency (Fujii Masao, Tom Lane)
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-11-06 [979766c0a] Correct the command tags for ALTER ... RENAME COLUMN.
-->

     <para>
      Fix <link linkend="sql-alterforeigntable"><command>ALTER FOREIGN
      TABLE ... RENAME COLUMN</command></link> to return a more appropriate
      command tag (Fujii Masao)
     </para>

     <para>
      Previously it returned <command>ALTER TABLE</command>; now it returns
      <command>ALTER FOREIGN TABLE</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-11-06 [979766c0a] Correct the command tags for ALTER ... RENAME COLUMN.
-->

     <para>
      Fix <link linkend="sql-altermaterializedview"><command>ALTER
      MATERIALIZED VIEW ... RENAME COLUMN</command></link> to return a more
      appropriate command tag (Fujii Masao)
     </para>

     <para>
      Previously it returned <command>ALTER TABLE</command>; now it returns
      <command>ALTER MATERIALIZED VIEW</command>.
     </para>
    </listitem>

    <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-07-20 [f5dff45962] Rename wal_keep_segments to wal_keep_size.
-->

     <para>
      Rename configuration parameter <varname>wal_keep_segments</varname>
      to <xref linkend="guc-wal-keep-size"/> (Fujii Masao)
     </para>

     <para>
      This determines how much WAL to retain for standby servers.
      It is specified in megabytes, rather than number of files as with
      the old parameter. If you
      previously used <varname>wal_keep_segments</varname>,
      the following formula will give you an approximately equivalent setting:
<programlisting>
wal_keep_size = wal_keep_segments * wal_segment_size (typically 16MB)
</programlisting>
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-05 [84eca14bc] Remove ancient hacks to ignore certain opclass names in
-->

     <para>
      Remove support for defining <link linkend="sql-createopclass">operator
      classes</link> using pre-<productname>PostgreSQL</productname>
      8.0 syntax (Daniel Gustafsson)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-05 [e58a59975] Remove ancient support for upgrading pre-7.3 foreign key
-->

     <para>
      Remove support for defining <link linkend="sql-altertable">foreign key
      constraints</link> using pre-<productname>PostgreSQL</productname>
      7.3 syntax (Daniel Gustafsson)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-05 [bb03010b9] Remove the "opaque" pseudo-type and associated compatibi
-->

     <para>
      Remove support for "opaque" <link
      linkend="sql-createtype">pseudo-types</link> used by
      pre-<productname>PostgreSQL</productname> 7.3 servers (Daniel
      Gustafsson)
     </para>
    </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-02-19 [70a773200] Remove support for upgrading extensions from "unpackaged
-->

      <para>
       Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
      </para>

      <para>
       The <literal>FROM</literal> option
       of <link linkend="sql-createextension"><command>CREATE
       EXTENSION</command></link> is no longer supported.  Any installations
       still using unpackaged extensions should upgrade them to a packaged
       version before updating to <productname>PostgreSQL</productname> 13.
      </para>
     </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-06-29 [21aac2ff9] Remove support for timezone "posixrules" file.
-->

     <para>
      Remove support for <filename>posixrules</filename> files in the
      timezone database (Tom Lane)
     </para>

     <para>
      IANA's timezone group has deprecated this feature, meaning that it
      will gradually disappear from systems' timezone databases over the
      next few years.  Rather than have a behavioral change appear
      unexpectedly with a timezone data update, we have
      removed <productname>PostgreSQL</productname>'s support for this
      feature as of version 13.  This affects only the behavior
      of <link linkend="datetime-posix-timezone-specs">POSIX-style time
      zone specifications</link> that lack an explicit daylight savings
      transition rule; formerly the transition rule could be determined
      by installing a custom <filename>posixrules</filename> file, but
      now it is hard-wired.  The recommended fix for any affected
      installations is to start using a geographical time zone name.
     </para>
    </listitem>

    <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-28 [9950c8aad] Fix lquery's behavior for consecutive '*' items.
-->

     <para>
      In <xref linkend="ltree"/>, when an <type>lquery</type> pattern
      contains adjacent asterisks with braces,
      e.g., <literal>*{2}.*{3}</literal>, properly interpret that
      as <literal>*{5}</literal> (Nikita Glukhov)
     </para>
    </listitem>

    <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
2020-03-07 [691e8b2e1] pageinspect: Fix types used for bt_metap() columns.
-->

     <para>
      Fix <xref linkend="pageinspect"/>'s <function>bt_metap()</function>
      to return more appropriate data types that are less likely to overflow
      (Peter Geoghegan)
     </para>
    </listitem>

   </itemizedlist>

  </sect2>

  <sect2>
   <title>Changes</title>

     <para>
       Below you will find a detailed account of the changes between
       <productname>PostgreSQL</productname> 13 and the previous major
       release.
     </para>

   <sect3>
    <title>Server</title>

    <sect4>
     <title><link linkend="ddl-partitioning">Partitioning</link></title>

     <itemizedlist>

      <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much
-->

       <para>
        Allow <link linkend="ddl-partition-pruning">pruning</link> of
        partitions to happen in more cases
        (Yuzuko Hosoya, Amit Langote, &Aacute;lvaro Herrera)
       </para>
      </listitem>

      <listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
-->

      <para>
       Allow <link linkend="guc-enable-partitionwise-join">partitionwise
       joins</link> to happen in more cases (Ashutosh Bapat, Etsuro Fujita,
       Amit Langote, Tom Lane)
      </para>

       <para>
        For example, partitionwise joins can now happen between partitioned
        tables even when their partition bounds do not match exactly.
       </para>
      </listitem>

      <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-18 [487e9861d] Enable BEFORE row-level triggers for partitioned tables
-->

       <para>
        Support row-level <literal>BEFORE</literal> <link
        linkend="triggers">triggers</link> on partitioned tables (&Aacute;lvaro
        Herrera)
       </para>

       <para>
        However, such a trigger is not allowed to change which partition
        is the destination.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
-->

       <para>
        Allow partitioned tables to be logically replicated via <link
        linkend="sql-createpublication">publications</link> (Amit Langote)
       </para>

       <para>
        Previously, partitions had to be replicated individually.  Now a
        partitioned table can be published explicitly, causing all its
        partitions to be published automatically.  Addition/removal of a
        partition causes it to be likewise added to or removed from the
        publication.
        The <link linkend="sql-createpublication"><command>CREATE
        PUBLICATION</command></link> option
        <literal>publish_via_partition_root</literal> controls whether changes
        to partitions are published as their own changes or their parent's.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
-->

       <para>
        Allow logical replication into partitioned tables on subscribers
        (Amit Langote)
       </para>

       <para>
        Previously, subscribers could only receive rows into non-partitioned
        tables.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-12-25 [bb4114a4e] Allow whole-row Vars to be used in partitioning expressi
-->

       <para>
        Allow whole-row variables (that
        is, <replaceable>table</replaceable><literal>.*</literal>) to be
        used in partitioning expressions (Amit Langote)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title>Indexes</title>

     <itemizedlist>

      <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
2020-02-26 [0d861bbb7] Add deduplication to nbtree.
-->

       <para>
        More efficiently store <link
        linkend="btree-deduplication">duplicates</link> in B-tree indexes
        (Anastasia Lubennikova, Peter Geoghegan)
       </para>

       <para>
        This allows efficient B-tree indexing of low-cardinality columns
        by storing duplicate keys only once.  Users upgrading with <link
        linkend="pgupgrade"><application>pg_upgrade</application></link>
        will need to use <link
        linkend="sql-reindex"><command>REINDEX</command></link> to make an
        existing index use this feature.
       </para>
      </listitem>

      <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2019-07-14 [c085e1c1c] Add support for <-> (box, point) operator to GiST box_op
Author: Alexander Korotkov <akorotkov@postgresql.org>
2019-07-14 [075f0a880] Add support for <-> (box, point) operator to SP-GiST box
-->

       <para>
        Allow <link linkend="gist">GiST</link> and <link
        linkend="spgist">SP-GiST</link> indexes on <type>box</type>
        columns to support <literal>ORDER BY <replaceable>box</replaceable>
        &lt;-&gt; <replaceable>point</replaceable></literal> queries (Nikita
        Glukhov)
       </para>
      </listitem>

      <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2020-01-18 [4b754d6c1] Avoid full scan of GIN indexes when possible
-->

       <para>
        Allow <link linkend="gin"><acronym>GIN</acronym></link> indexes to
        more efficiently handle <literal>!</literal> (NOT) clauses
        in <type>tsquery</type> searches (Nikita
        Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud)
       </para>
      </listitem>

      <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2020-03-30 [911e70207] Implement operator class parameters
-->

       <para>
        Allow <link linkend="sql-createindex">index operator classes</link>
        to take parameters (Nikita Glukhov)
       </para>
      </listitem>

      <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2020-03-30 [911e70207] Implement operator class parameters
-->

       <para>
        Allow <command>CREATE INDEX</command> to specify the GiST signature
        length and maximum number of integer ranges (Nikita Glukhov)
       </para>

       <para>
        Indexes created on four and eight-byte <link linkend="intarray">integer
        array</link>, <link linkend="textsearch">tsvector</link>,
        <xref linkend="pgtrgm"/>, <xref linkend="ltree"/>, and <xref
        linkend="hstore"/> columns can now control these GiST index parameters,
        rather than using the defaults.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-12-06 [fbbf68094] Disallow non-default collation in ADD PRIMARY KEY/UNIQUE
-->

       <para>
        Prevent indexes that use non-default collations from being <link
        linkend="sql-altertable">added</link> as a table's unique or primary
        key constraint (Tom Lane)
       </para>

       <para>
        The index's collation must match that of the underlying column,
        but <command>ALTER TABLE</command> previously failed to check
        this.
       </para>
      </listitem>


     </itemizedlist>

    </sect4>

    <sect4>
     <title>Optimizer</title>

     <itemizedlist>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-01 [a80818605] Improve selectivity estimation for assorted match-style
-->

       <para>
        Improve the optimizer's <link
        linkend="planner-stats-details">selectivity</link> estimation for
        containment/match operators (Tom Lane)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2019-09-11 [d06215d03] Allow setting statistics target for extended statistics
-->

       <para>
        Allow setting the <link linkend="sql-altertable">statistics target</link>
        for <link linkend="sql-createstatistics">extended statistics</link>
        (Tomas Vondra)
       </para>

       <para>
        This is controlled with the new command option <command>ALTER
        STATISTICS ... SET STATISTICS</command>.  Previously this was computed
        based on more general statistics target settings.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-01-13 [aaa676187] Apply all available functional dependencies
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-01-13 [eae056c19] Apply multiple multivariate MCV lists when possible
-->

       <para>
        Allow use of multiple extended statistics objects in a single query
        (Tomas Vondra)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-03-14 [8f321bd16] Use functional dependencies to estimate ScalarArrayOpExp
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-03-14 [e83daa7e3] Use multi-variate MCV lists to estimate ScalarArrayOpExp
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-03-18 [ccaa3569f] Recognize some OR clauses as compatible with functional
-->

       <para>
        Allow use of extended statistics objects for OR clauses and <link
        linkend="functions-subquery">IN</link>/<literal>ANY</literal> constant
        lists (Pierre Ducroquet, Tomas Vondra)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-08-01 [7266d0997] Allow functions-in-FROM to be pulled up if they reduce t
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-09-24 [a9ae99d01] Prevent bogus pullup of constant-valued functions return
-->

       <para>
        Allow functions in <literal>FROM</literal> clauses to be pulled up
        (inlined) if they evaluate to constants (Alexander Kuzmenkov,
        Aleksandr Parfenov)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title>General Performance</title>

     <itemizedlist>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-04-06 [d2d8a229b] Implement Incremental Sort
Author: Peter Eisentraut <peter@eisentraut.org>
2020-07-05 [94e454cdd] Rename enable_incrementalsort for clarity
-->

       <para>
        Implement <link linkend="guc-enable-incremental-sort">incremental
        sorting</link> (James Coleman, Alexander Korotkov, Tomas Vondra)
       </para>

       <para>
        If an intermediate query result is known to be sorted by
        one or more leading keys of a required sort ordering, the
        additional sorting can be done considering only the remaining
        keys, if the rows are sorted in batches that have equal leading
        keys.
       </para>

       <para>
        If necessary, this can be controlled using <xref
        linkend="guc-enable-incremental-sort"/>.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
2019-08-01 [71dcd7438] Add sort support routine for the inet data type.
-->

       <para>
        Improve the performance of sorting <link
        linkend="datatype-inet">inet</link> values (Brandur Leach)
       </para>
      </listitem>

      <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
2020-03-18 [1f39bce02] Disk-based Hash Aggregation.
Author: Jeff Davis <jdavis@postgresql.org>
2020-03-24 [dd8e19132] Consider disk-based hash aggregation to implement DISTIN
Author: Peter Geoghegan <pg@bowt.ie>
2020-07-29 [78530c8e7] Add hash_mem_multiplier GUC.
-->

       <para>
        Allow <link linkend="guc-enable-hashagg">hash aggregation</link>
        to use disk storage for large aggregation result sets (Jeff Davis)
       </para>

       <para>
        Previously, hash aggregation was avoided if it was expected to use
        more than <xref linkend="guc-work-mem"/> memory.  Now, a hash
        aggregation plan can be chosen despite that.  The hash table will
        be spilled to disk if it exceeds <varname>work_mem</varname> times
        <xref linkend="guc-hash-mem-multiplier"/>.
       </para>

       <para>
        This behavior is normally preferable to the old behavior, in which
        once hash aggregation had been chosen, the hash table would be
        kept in memory no matter how large it got &mdash; which could be
        very large if the planner had misestimated.  If necessary,
        behavior similar to that can be obtained by
        increasing <varname>hash_mem_multiplier</varname>.
       </para>
      </listitem>

      <listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
2020-03-28 [b07642dbc] Trigger autovacuum based on number of INSERTs
-->

       <para>
        Allow inserts, not only updates and deletes, to trigger vacuuming
        activity in <link linkend="autovacuum">autovacuum</link>
        (Laurenz Albe, Darafei Praliaskouski)
       </para>

       <para>
        Previously, insert-only activity would trigger auto-analyze but
        not auto-vacuum, on the grounds that there could not be any dead
        tuples to remove.  However, a vacuum scan has other useful
        side-effects such as setting page-all-visible bits, which improves
        the efficiency of index-only scans.  Also, allowing an insert-only
        table to receive periodic vacuuming helps to spread out the work
        of <quote>freezing</quote> old tuples, so that there is not
        suddenly a large amount of freezing work to do when the entire
        table reaches the anti-wraparound threshold all at once.
       </para>

       <para>
        If necessary, this behavior can be adjusted with the new
        parameters <xref linkend="guc-autovacuum-vacuum-insert-threshold"/>
        and <xref linkend="guc-autovacuum-vacuum-insert-scale-factor"/>, or
        the equivalent table storage options.
       </para>
      </listitem>

      <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-03-16 [fc34b0d9d] Introduce a maintenance_io_concurrency setting.
-->

       <para>
        Add <xref linkend="guc-maintenance-io-concurrency"/> parameter to
        control I/O concurrency for maintenance operations (Thomas Munro)
       </para>
      </listitem>

      <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
2020-04-04 [c6b92041d] Skip WAL for new relfilenodes, under wal_level=minimal.
-->

       <para>
        Allow <acronym>WAL</acronym> writes to be skipped during a transaction
        that creates or rewrites a relation, if <xref
        linkend="guc-wal-level"/> is <literal>minimal</literal> (Kyotaro
        Horiguchi)
       </para>

       <para>
        Relations larger than <xref linkend="guc-wal-skip-threshold"/>
        will have their files fsync'ed rather than generating
        <acronym>WAL</acronym>.  Previously this was done only for
        <command>COPY</command> operations, but the implementation had a bug
        that could cause data loss during crash recovery.
       </para>
      </listitem>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-11-21 [e6d806952] Make DROP DATABASE command generate less WAL records.
-->

       <para>
        Improve performance when replaying <link
        linkend="sql-dropdatabase"><command>DROP DATABASE</command></link>
        commands when many tablespaces are in use (Fujii Masao)
       </para>
      </listitem>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-09-24 [6d05086c0] Speedup truncations of relation forks.
-->

       <para>
        Improve performance for <link linkend="sql-truncate">truncation</link>
        of very large relations (Kirk Jamison)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2019-10-01 [11a078cf8] Optimize partial TOAST decompression
-->

       <para>
        Improve retrieval of the leading bytes of <link
        linkend="storage-toast"><acronym>TOAST</acronym></link>'ed values
        (Binguo Bao, Andrey Borodin)
       </para>

       <para>
        Previously, compressed out-of-line <acronym>TOAST</acronym> values
        were fully fetched even when it's known that only some leading
        bytes are needed.  Now, only enough data to produce the result is
        fetched.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-09-10 [bca6e6435] Reduce overhead of scanning the backend[] array in LISTE
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-09-22 [51004c717] Make some efficiency improvements in LISTEN/NOTIFY.
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-08-15 [bb5ae8f6c] Use a hash table to de-duplicate NOTIFY events faster.
-->

       <para>
        Improve performance of <link
        linkend="sql-listen"><command>LISTEN</command></link>/<command>NOTIFY</command>
        (Martijn van Oosterhout, Tom Lane)
       </para>
      </listitem>

      <listitem>
<!--
Author: Andrew Gierth <rhodiumtoad@postgresql.org>
2020-02-01 [1fd687a03] Optimizations for integer to decimal output.
-->

       <para>
        Speed up conversions of integers to text (David Fetter)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-07-10 [b5810de3f] Reduce memory consumption for multi-statement query stri
-->

       <para>
        Reduce memory usage for query strings and extension scripts that
        contain many <acronym>SQL</acronym> statements (Amit Langote)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title>Monitoring</title>

     <itemizedlist>

      <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2020-04-05 [6b466bf5f] Allow pg_stat_statements to track WAL usage statistics.
Author: Amit Kapila <akapila@postgresql.org>
2020-04-06 [33e05f89c] Add the option to report WAL usage in EXPLAIN and auto_e
Author: Amit Kapila <akapila@postgresql.org>
2020-04-06 [b7ce6de93] Allow autovacuum to log WAL usage statistics.
-->

       <para>
        Allow <link linkend="sql-explain"><command>EXPLAIN</command></link>,
        <xref linkend="auto-explain"/>, <link
        linkend="autovacuum">autovacuum</link>, and <xref
        linkend="pgstatstatements"/> to track <acronym>WAL</acronym> usage
        statistics (Kirill Bychik, Julien Rouhaud)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2019-11-06 [6e3e6cc0e] Allow sampling of statements depending on duration
-->

       <para>
        Allow a sample of SQL statements, rather than all statements, to
        be logged (Adrien Nayrat)
       </para>

       <para>
        A <xref linkend="guc-log-statement-sample-rate"/> fraction of
        those statements taking more than
        <xref linkend="guc-log-min-duration-sample"/> duration will be
        logged.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-15 [70a7b4776] Add backend type to csvlog and optionally log_line_prefi
-->

       <para>
        Add the backend type to <link
        linkend="runtime-config-logging">csvlog</link> and optionally <xref
        linkend="guc-log-line-prefix"/> log output (Peter Eisentraut)
       </para>
      </listitem>

      <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-12-11 [ba79cb5dc] Emit parameter values during query bind/execute errors
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-02 [0b34e7d30] Improve user control over truncation of logged bind-para
-->

       <para>
        Improve control of prepared statement parameter logging (Alexey
        Bashtanov, &Aacute;lvaro Herrera)
       </para>

       <para>
        The <acronym>GUC</acronym> setting <xref
        linkend="guc-log-parameter-max-length"/> controls the maximum length
        of parameter values output during logging of non-error statements,
        while <xref linkend="guc-log-parameter-max-length-on-error"/> does
        the same for logging of statements with errors.  Previously,
        prepared statement parameters were never logged during errors.
       </para>
      </listitem>

      <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-11-08 [71a8a4f6e] Add backtrace support for error reporting
Author: Peter Eisentraut <peter@eisentraut.org>
2020-07-10 [8ff4d1277] Log the location field before any backtrace
-->

       <para>
        Allow function call backtraces to be logged after errors (Peter
        Eisentraut, &Aacute;lvaro Herrera)
       </para>

       <para>
        The new parameter <xref linkend="guc-backtrace-functions"/> specifies
        which C functions should generate backtraces on error.
       </para>
      </listitem>

      <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-02-05 [15d13e829] Make vacuum buffer counters 64 bits wide
-->

       <para>
        Make <link linkend="sql-vacuum">vacuum</link> buffer counters 64-bits
        wide to avoid overflow (&Aacute;lvaro Herrera)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title>System Views</title>

     <itemizedlist>

      <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-02-06 [b025f32e0] Add leader_pid to pg_stat_activity
-->

       <para>
        Add <structfield>leader_pid</structfield> to <xref
        linkend="pg-stat-activity-view"/> to report a parallel worker's
        leader process (Julien Rouhaud)
       </para>
      </listitem>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-03-03 [e65497df8] Report progress of streaming base backup.
-->

       <para>
        Add system view <link
        linkend="basebackup-progress-reporting"><structname>pg_stat_progress_basebackup</structname></link>
        to report the progress of streaming base backups (Fujii Masao)
       </para>
      </listitem>

      <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-01-15 [a166d408e] Report progress of ANALYZE commands
-->

       <para>
        Add system view <link
        linkend="monitoring-stats-dynamic-views-table"><structname>pg_stat_progress_analyze</structname></link>
        to report <link linkend="sql-analyze">ANALYZE</link> progress
        (&Aacute;lvaro Herrera, Tatsuro Yamada, Vinayak Pokale)
       </para>
      </listitem>

      <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
2020-01-09 [ed10f32e3] Add pg_shmem_allocations view.
-->

       <para>
        Add system view <link
        linkend="view-pg-shmem-allocations"><structname>pg_shmem_allocations</structname></link>
        to display shared memory usage (Andres Freund, Robert Haas)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
2020-04-02 [28cac71bd] Collect statistics about SLRU caches
-->

       <para>
        Add system view <link
        linkend="monitoring-stats-views-table"><structname>pg_stat_slru</structname></link>
        to monitor internal <acronym>SLRU</acronym> caches
        (Tomas Vondra)
       </para>
      </listitem>

      <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
2020-01-07 [814727858] Increase the maximum value of track_activity_query_size.
-->

       <para>
        Allow <xref linkend="guc-track-activity-query-size"/> to be set as
        high as 1MB (Vyacheslav Makarov)
       </para>

       <para>
        The previous maximum was 100kB.
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title><link linkend="wait-event-table">Wait Events</link></title>

     <itemizedlist>

      <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-01-31 [ef02fb15a] Report time spent in posix_fallocate() as a wait event.
-->

       <para>
        Report a wait event while creating a DSM segment
        with <function>posix_fallocate()</function> (Thomas Munro)
       </para>
      </listitem>

      <listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
2020-03-23 [cedffbdb8] Report wait event for cost-based vacuum delay.
-->

       <para>
        Add wait event VacuumDelay to report on cost-based vacuum delay
        (Justin Pryzby)
       </para>
      </listitem>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-03-24 [b8e20d6da] Add wait events for WAL archive and recovery pause.
-->

       <para>
        Add wait events for <acronym>WAL</acronym> archive and recovery pause
        (Fujii Masao)
       </para>

       <para>
        The new events are BackupWaitWalArchive and RecoveryPause.
       </para>
      </listitem>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-04-03 [18808f8c8] Add wait events for recovery conflicts.
-->

       <para>
        Add  wait events RecoveryConflictSnapshot and
        RecoveryConflictTablespace to monitor recovery conflicts (Masahiko
        Sawada)
       </para>
      </listitem>

      <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-02-05 [815c2f097] Add kqueue(2) support to the WaitEventSet API.
-->

       <para>
        Improve performance of wait events on <acronym>BSD</acronym>-based
        systems (Thomas Munro)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title><acronym>Authentication</acronym></title>

     <itemizedlist>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-03-09 [d9249441e] Mark ssl_passphrase_command as GUC_SUPERUSER_ONLY.
-->

       <para>
        Allow only superusers to view the <xref
        linkend="guc-ssl-passphrase-command"/> setting (Insung Moon)
       </para>

       <para>
        This was changed as a security precaution.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-12-04 [b1abfec82] Update minimum SSL version
-->

       <para>
        Change the server's default minimum <acronym>TLS</acronym> version
        for encrypted connections from 1.0 to 1.2 (Peter Eisentraut)
       </para>

       <para>
        This choice can be controlled by
        <xref linkend="guc-ssl-min-protocol-version"/>.
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title>Server Configuration</title>

     <itemizedlist>

      <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
2020-01-16 [2eb34ac36] Fix problems with "read only query" checks, and refactor
-->

       <para>
        Tighten rules on which utility commands are allowed in
        read-only transaction mode (Robert Haas)
       </para>

       <para>
        This change also increases the number of utility commands that can
        run in parallel queries.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-11-29 [c4a7a392e] Make allow_system_table_mods settable at run time
-->

       <para>
        Allow <xref linkend="guc-allow-system-table-mods"/> to be changed
        after server start (Peter Eisentraut)
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-11-29 [508bf95b7] Remove any-user DML capability from allow_system_table_m
-->

       <para>
        Disallow non-superusers from modifying system tables when <xref
        linkend="guc-allow-system-table-mods"/> is set (Peter Eisentraut)
       </para>

       <para>
        Previously, if <xref linkend="guc-allow-system-table-mods"/>
        was set at server start, non-superusers could issue
        <command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>
        commands on system tables.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-28 [8f3ec75de] Enable Unix-domain sockets support on Windows
-->

       <para>
        Enable support
        for <link linkend="runtime-config-connection-settings">Unix-domain
        sockets</link> on Windows (Peter Eisentraut)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

   </sect3>

   <sect3>
    <title>Streaming Replication and Recovery</title>

    <itemizedlist>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-27 [1e6148032] Allow walreceiver configuration to change on reload
-->

      <para>
       Allow streaming replication configuration settings to be changed by
       reload (Sergei Kornilov)
      </para>

      <para>
       Previously, a server restart was required to change
       <xref linkend="guc-primary-conninfo"/> and <xref
       linkend="guc-primary-slot-name"/>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-01-14 [329730827] walreceiver uses a temporary replication slot by default
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-27 [092c6936d] Set wal_receiver_create_temp_slot PGC_POSTMASTER
-->

      <para>
       Allow <acronym>WAL</acronym> receivers to use a temporary
       replication slot when a permanent one is not specified (Peter
       Eisentraut, Sergei Kornilov)
      </para>

      <para>
       This behavior can be enabled using <xref
       linkend="guc-wal-receiver-create-temp-slot"/>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-04-07 [c65507763] Allow users to limit storage reserved by replication slo
-->

      <para>
       Allow WAL storage for replication slots to be limited by
       <xref linkend="guc-max-slot-wal-keep-size"/> (Kyotaro Horiguchi)
      </para>

      <para>
       Replication slots that would require exceeding this value are
       marked invalid.
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-03-24 [496ee647e] Prefer standby promotion over recovery pause.
-->

      <para>
       Allow <link linkend="guc-promote-trigger-file">standby promotion</link>
       to cancel any requested pause (Fujii Masao)
      </para>

      <para>
       Previously, promotion could not happen while the standby was in
       paused state.
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-01-29 [dc788668b] Fail if recovery target is not reached
-->

      <para>
       Generate an error if recovery does not reach the specified <link
       linkend="runtime-config-wal-recovery-target">recovery target</link>
       (Leif Gunnar Erlandsen, Peter Eisentraut)
      </para>

      <para>
       Previously, a standby would promote itself upon reaching the end
       of <acronym>WAL</acronym>, even if the target was not reached.
      </para>
     </listitem>

     <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2019-11-19 [cec2edfa7] Add logical_decoding_work_mem to limit ReorderBuffer mem
-->

      <para>
       Allow control over how much memory is used by logical decoding before
       it is spilled to disk (Tomas Vondra, Dilip Kumar, Amit Kapila)
      </para>

      <para>
       This is controlled by <xref linkend="guc-logical-decoding-work-mem"/>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-01-22 [41c184bc6] Add GUC ignore_invalid_pages.
-->

      <para>
       Allow recovery to continue even if invalid
       pages are referenced by <acronym>WAL</acronym> (Fujii Masao)
      </para>

      <para>
       This is enabled using <xref linkend="guc-ignore-invalid-pages"/>.
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Utility Commands</title>

    <itemizedlist>

     <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2020-01-20 [40d964ec9] Allow vacuum command to process indexes in parallel.
-->

      <para>
       Allow <link linkend="sql-vacuum"><command>VACUUM</command></link>
       to process a table's indexes in parallel (Masahiko Sawada, Amit Kapila)
      </para>

      <para>
       The new <literal>PARALLEL</literal> option controls this.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-04-07 [357889eb1] Support FETCH FIRST WITH TIES
-->

      <para>
       Allow <link linkend="sql-limit"><command>FETCH FIRST</command></link>
       to use <literal>WITH TIES</literal> to return any additional rows
       that match the last result row (Surafel Temesgen)
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-04-04 [ce77abe63] Include information on buffer usage during planning phas
-->

      <para>
       Report planning-time buffer usage in <link
       linkend="sql-explain"><command>EXPLAIN</command></link>'s
       <literal>BUFFER</literal> output (Julien Rouhaud)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-10 [cacef1722] Ensure that CREATE TABLE LIKE copies any NO INHERIT cons
-->

      <para>
       Make <link linkend="sql-createtable"><command>CREATE TABLE
       LIKE</command></link> propagate a <literal>CHECK</literal>
       constraint's <literal>NO INHERIT</literal> property to the created
       table (Ildar Musin, Chris Travers)
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-02-18 [b7e51b350] Make inherited LOCK TABLE perform access permission chec
-->

      <para>
       When using <link linkend="sql-lock"><command>LOCK
       TABLE</command></link> on a partitioned table, do not check permissions
       on the child tables (Amit Langote)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-31 [de3bbfcc9] Fix INSERT OVERRIDING USER VALUE behavior
-->

      <para>
       Allow <link linkend="sql-insert"><literal>OVERRIDING USER
       VALUE</literal></link> on inserts into identity columns (Dean Rasheed)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-01-14 [f595117e2] ALTER TABLE ... ALTER COLUMN ... DROP EXPRESSION
-->

      <para>
       Add <link linkend="sql-altertable"><command>ALTER
       TABLE ... DROP EXPRESSION</command></link>
       to allow removing the <literal>GENERATED</literal>
       property from a column (Peter Eisentraut)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-01-15 [1281a5c90] Restructure ALTER TABLE execution to fix assorted bugs.
-->

      <para>
       Fix bugs in multi-step <command>ALTER TABLE</command> commands (Tom
       Lane)
      </para>

      <para>
       <literal>IF NOT EXISTS</literal> clauses now work as expected, in
       that derived actions (such as index creation) do not execute if the
       column already exists.  Also, certain cases of combining related
       actions into one <command>ALTER TABLE</command> now work when they
       did not before.
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-11-21 [30840c92a] Allow ALTER VIEW command to rename the column in the vie
-->

      <para>
       Add <link linkend="sql-alterview"><command>ALTER VIEW</command></link>
       syntax to rename view columns (Fujii Masao)
      </para>

      <para>
       Renaming view columns was already possible, but one had to
       write <command>ALTER TABLE RENAME COLUMN</command>, which is
       confusing.
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-06 [fe30e7ebf] Allow ALTER TYPE to change some properties of a base typ
-->

      <para>
       Add <link linkend="sql-altertype"><command>ALTER TYPE</command></link>
       options to modify a base type's <acronym>TOAST</acronym> properties
       and support functions (Tomas Vondra, Tom Lane)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-07-23 [06140c201] Add CREATE DATABASE LOCALE option
-->

      <para>
       Add <link linkend="sql-createdatabase"><command>CREATE
       DATABASE</command></link> <literal>LOCALE</literal> option (Peter
       Eisentraut)
      </para>

      <para>
       This combines the existing options <literal>LC_COLLATE</literal> and
       <literal>LC_CTYPE</literal> into a single option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2019-11-13 [1379fd537] Introduce the 'force' option for the Drop Database comma
-->

      <para>
       Allow <link linkend="sql-dropdatabase"><command>DROP
       DATABASE</command></link> to disconnect sessions using the target
       database, allowing the drop to succeed (Pavel Stehule, Amit Kapila)
      </para>

      <para>
       This is enabled by the <literal>FORCE</literal> option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-09 [71d60e2aa] Add tg_updatedcols to TriggerData
-->

      <para>
       Add structure member <link
       linkend="trigger-interface"><structfield>tg_updatedcols</structfield></link>
       to allow C-language update triggers to know which column(s) were updated
       (Peter Eisentraut)
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Data Types</title>

    <itemizedlist>

     <listitem>
<!--
Tom Lane <tgl@sss.pgh.pa.us>
2020-03-19 [24e2885ee] Introduce "anycompatible" family of polymorphic types.
-->

      <para>
       Add polymorphic data types for use by functions requiring compatible
       arguments (Pavel Stehule)
      </para>

      <para>
       The new data types are <link
       linkend="datatype-pseudotypes-table"><type>anycompatible</type></link>,
       <type>anycompatiblearray</type>, <type>anycompatiblenonarray</type>,
       and <type>anycompatiblerange</type>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-04-07 [aeec457de] Add SQL type xid8 to expose FullTransactionId to users.
-->

      <para>
       Add <acronym>SQL</acronym> data type <link
       linkend="datatype-oid"><type>xid8</type></link> to expose
       FullTransactionId (Thomas Munro)
      </para>

      <para>
       The existing <type>xid</type> data type is only four bytes so it
       does not provide the transaction epoch.
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-03-18 [a2b1faa0f] Implement type regcollation
-->

      <para>
       Add data
       type <link linkend="datatype-oid"><type>regcollation</type></link>
       and associated functions, to represent OIDs of collation objects
       (Julien Rouhaud)
      </para>
     </listitem>

     <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2019-10-16 [d5ac14f9c] Use libc version as a collation version on glibc systems
-->

      <para>
       Use the glibc version in some cases as a <link
       linkend="collation">collation</link> version identifier (Thomas Munro)
      </para>

      <para>
       If the glibc version changes, a warning will be issued about
       possible corruption of collation-dependent indexes.
      </para>
     </listitem>

     <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-03-25 [352f6f2df] Add collation versions for Windows.
-->

      <para>
       Add support for collation versions on Windows (Thomas Munro)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-10-28 [8b7a0f1d1] Allow extracting fields from a ROW() expression in more
-->

      <para>
       Allow <link linkend="sql-syntax-row-constructors"><literal>ROW</literal>
       expressions</link> to have their members extracted with suffix
       notation (Tom Lane)
      </para>

      <para>
       For example, <literal>(ROW(4, 5.0)).f1</literal> now returns 4.
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Functions</title>

    <itemizedlist>

     <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2020-01-17 [a83586b55] Add a non-strict version of jsonb_set
-->

      <para>
       Add alternate version of <link
       linkend="functions-json-processing-table"><function>jsonb_set()</function></link>
       with improved <literal>NULL</literal> handling (Andrew Dunstan)
      </para>

      <para>
       The new function, <function>jsonb_set_lax()</function>, handles a
       <literal>NULL</literal> new value by either setting the specified
       key to a <acronym>JSON</acronym> null, deleting the key, raising an
       exception, or returning the <type>jsonb</type> value unmodified, as
       requested.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2019-09-25 [bffe1bd68] Implement jsonpath .datetime() method
-->

      <para>
       Add jsonpath <link
       linkend="functions-sqljson-path-operators">.<function>datetime()</function></link>
       method (Nikita Glukhov, Teodor Sigaev, Oleg Bartunov, Alexander
       Korotkov)
      </para>

      <para>
       This function allows <acronym>JSON</acronym> values to be converted
       to timestamps, which can then be processed in <type>jsonpath</type>
       expressions.  This change also adds <type>jsonpath</type> functions
       that support time-zone-aware output.
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-04-02 [2991ac5fc] Add SQL functions for Unicode normalization
-->

      <para>
       Add <acronym>SQL</acronym> functions <link
       linkend="functions-string-sql"><literal>NORMALIZE</literal>()</link>
       to normalize Unicode strings, and <link
       linkend="collation-nondeterministic"><literal>IS
       NORMALIZED</literal></link> to check for normalization (Peter
       Eisentraut)
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2019-07-05 [313f87a17] Add min() and max() aggregates for pg_lsn
-->

      <para>
       Add <function>min()</function> and
       <function>max()</function> aggregates for <link
       linkend="datatype-pg-lsn"><type>pg_lsn</type></link> (Fabr&iacute;zio
       de Royes Mello)
      </para>

      <para>
       These are particularly useful in monitoring queries.
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-06 [a6525588b] Allow Unicode escapes in any server encoding, not only U
-->

      <para>
       Allow <link linkend="sql-syntax-strings-uescape">Unicode
       escapes</link>,
       e.g., <literal>E'\u<replaceable>nnnn</replaceable>'</literal>
       or <literal>U&amp;'\<replaceable>nnnn</replaceable>'</literal>, to
       specify any character available in the database encoding, even when
       the database encoding is not <acronym>UTF</acronym>-8 (Tom Lane)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-03 [d67755049] Allow to_date/to_timestamp to recognize non-English mont
-->

      <para>
       Allow <link
       linkend="functions-formatting"><function>to_date()</function></link>
       and <function>to_timestamp()</function> to recognize non-English
       month/day names (Juan Jos&eacute; Santamar&iacute;a Flecha, Tom Lane)
      </para>

      <para>
       The names recognized are the same as those output by <link
       linkend="functions-formatting"><function>to_char()</function></link>
       with the same format patterns.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2019-09-16 [d589f9446] Support for FF1-FF6 datetime format patterns
-->

      <para>
       Add datetime format patterns <literal>FF1</literal>
       &ndash; <literal>FF6</literal> to specify input or output of
       1 to 6 fractional-second digits (Alexander
       Korotkov, Nikita Glukhov, Teodor Sigaev, Oleg Bartunov)
      </para>

      <para>
       These patterns can be used by <function>to_char()</function>,
       <function>to_timestamp()</function>, and jsonpath's
       .<function>datetime()</function>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2019-09-16 [b64b857f5] Support for SSSSS datetime format pattern
-->

      <para>
       Add <literal>SSSSS</literal> datetime format pattern as an
       <acronym>SQL</acronym>-standard alias for <literal>SSSS</literal>
       (Nikita Glukhov, Alexander Korotkov)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-07-14 [5925e5549] Add gen_random_uuid function
-->

      <para>
       Add function <link
       linkend="functions-uuid"><function>gen_random_uuid()</function></link>
       to generate version-4 UUIDs (Peter Eisentraut)
      </para>

      <para>
       Previously <acronym>UUID</acronym> generation functions were only
       available in the external modules <xref linkend="uuid-ossp"/> and <xref
       linkend="pgcrypto"/>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
2020-01-25 [13661ddd7] Add functions gcd() and lcm() for integer and numeric ty
-->

      <para>
       Add greatest-common-denominator
       (<link linkend="functions-math-func-table"><function>gcd</function></link>)
       and least-common-multiple (<function>lcm</function>) functions (Vik
       Fearing)
      </para>
     </listitem>

     <listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
2020-03-01 [43a899f41] Fix corner-case loss of precision in numeric ln().
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
2020-03-28 [4083f445c] Improve the performance and accuracy of numeric sqrt() a
-->

      <para>
       Improve the performance and accuracy of the <type>numeric</type>
       type's <link linkend="functions-math-func-table">square root</link>
       (<function>sqrt</function>) and natural log
       (<function>ln</function>) functions (Dean Rasheed)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-01-06 [20d6225d1] Add functions min_scale(numeric) and trim_scale(numeric)
-->

      <para>
       Add function <link
       linkend="functions-math-func-table"><function>min_scale()</function></link>
       that returns the number of digits to the right of the decimal point
       that are required to represent a <type>numeric</type> value with
       full accuracy (Pavel Stehule)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-01-06 [20d6225d1] Add functions min_scale(numeric) and trim_scale(numeric)
-->

      <para>
       Add function <link
       linkend="functions-math-func-table"><function>trim_scale()</function></link>
       to reduce the scale of a <type>numeric</type> value by removing
       trailing zeros (Pavel Stehule)
      </para>
     </listitem>

     <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2019-07-14 [6254c55f8] Add missing commutators for distance operators
-->

      <para>
       Add commutators of <link linkend="functions-geometry-op-table">distance
       operators</link> (Nikita Glukhov)
      </para>

      <para>
       For example, previously only <type>point</type>
       <literal>&lt;-&gt;</literal> <type>line</type> was supported,
       now <type>line</type> <literal>&lt;-&gt;</literal> <type>point</type>
       works too.
      </para>
     </listitem>

     <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2020-04-07 [4c04be9b0] Introduce xid8-based functions to replace txid_XXX.
-->

      <para>
       Create <type>xid8</type> versions of all <link
       linkend="functions-pg-snapshot">transaction ID functions</link>
       (Thomas Munro)
      </para>

      <para>
       The old <type>xid</type>-based functions still exist, for backward
       compatibility.
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-07 [26a944cf2] Adjust bytea get_bit/set_bit to use int8 not int4 for bi
-->

      <para>
       Allow <link
       linkend="functions-binarystring-other"><function>get_bit()</function></link>
       and <function>set_bit()</function> to set bits beyond the first
       256MB of a <type>bytea</type> value (Movead Li)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-08-01 [4886da832] Mark advisory-lock functions as parallel restricted, not
-->

      <para>
       Allow <link linkend="functions-advisory-locks">advisory-lock
       functions</link> to be used in some parallel operations (Tom Lane)
      </para>
     </listitem>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-04-20 [5fc703946] Add ALTER .. NO DEPENDS ON
-->

      <para>
       Add the ability to remove an object's dependency on an extension
       (&Aacute;lvaro Herrera)
      </para>

      <para>
       The object can be a function, materialized view, index, or trigger.
       The syntax is <command>ALTER .. NO DEPENDS ON</command>.
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title><link linkend="plpgsql">PL/pgSQL</link></title>

    <itemizedlist>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-26 [8f59f6b9c] Improve performance of "simple expressions" in PL/pgSQL.
-->

      <para>
       Improve performance of simple PL/pgSQL expressions (Tom Lane,
       Amit Langote)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-11-22 [73b06cf89] Avoid taking a new snapshot for an immutable simple expr
-->

      <para>
       Improve performance of PL/pgSQL functions that use immutable
       expressions (Konstantin Knizhnik)
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Client Interfaces</title>

    <itemizedlist>

     <listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
2019-09-23 [d6e612f83] Add libpq parameter 'channel_binding'.
-->

      <para>
       Allow libpq clients to require channel binding for encrypted
       connections (Jeff Davis)
      </para>

      <para>
       Using the libpq connection parameter <link
       linkend="libpq-connect-channel-binding"><literal>channel_binding</literal></link>
       forces the other end of the <acronym>TLS</acronym> connection to prove
       it knows the user's password.  This prevents man-in-the-middle attacks.
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-01-28 [ff8ca5fad] Add connection parameters to control SSL protocol min/ma
Author: Michael Paquier <michael@paquier.xyz>
2020-04-30 [401aad670] Rename connection parameters to control min/max SSL prot
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-06-27 [16412c784] Change libpq's default ssl_min_protocol_version to TLSv1
-->

      <para>
       Add libpq connection parameters to control the minimum and maximum
       <acronym>TLS</acronym> version allowed for an encrypted connection
       (Daniel Gustafsson)
      </para>

      <para>
       The settings are <xref
       linkend="libpq-connect-ssl-min-protocol-version"/> and <xref
       linkend="libpq-connect-ssl-max-protocol-version"/>.
       By default, the minimum <acronym>TLS</acronym> version is 1.2
       (this represents a behavioral change from previous releases).
      </para>
     </listitem>

     <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2019-11-30 [4dc635521] libq support for sslpassword connection param,  DER form
-->

      <para>
       Allow use of passwords to unlock client certificates (Craig
       Ringer, Andrew Dunstan)
      </para>

      <para>
       This is enabled by libpq's <xref linkend="libpq-connect-sslpassword"/>
       connection parameter.
      </para>
     </listitem>

     <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2019-11-30 [4dc635521] libq support for sslpassword connection param,  DER form
-->

      <para>
       Allow libpq to use <acronym>DER</acronym>-encoded client
       certificates (Craig Ringer, Andrew Dunstan)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-08-03 [44cd434ec] Fix behavior of ecpg's "EXEC SQL elif name".
-->

      <para>
       Fix <application>ecpg</application>'s <literal>EXEC SQL
       elif</literal> directive to work correctly (Tom Lane)
      </para>

      <para>
       Previously it behaved the same as <literal>endif</literal> followed
       by <literal>ifdef</literal>, so that a successful previous branch
       of the same <literal>if</literal> construct did not prevent
       expansion of the <literal>elif</literal> branch or following
       branches.
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Client Applications</title>

    <sect4>
     <title><xref linkend="app-psql"/></title>

     <itemizedlist>

      <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-02-12 [dcdbb5a5d] Add %x to default PROMPT1 and PROMPT2 in psql
-->

       <para>
        Add transaction status (<literal>%x</literal>)
        to <application>psql</application>'s default
        <link linkend="app-psql-prompting">prompts</link> (Vik Fearing)
       </para>
      </listitem>

      <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2019-11-19 [7f338369c] Allow invisible PROMPT2 in psql.
-->

       <para>
        Allow the secondary <application>psql</application> prompt to be
        blank but the same width as the primary prompt (Thomas Munro)
       </para>

       <para>
        This is accomplished by setting <literal>PROMPT2</literal>
        to <literal>%w</literal>.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-07 [b63c293bc] Allow psql's \g and \gx commands to transiently change \
-->

       <para>
        Allow <application>psql</application>'s
        <link linkend="app-psql-meta-commands"><literal>\g</literal></link>
        and <literal>\gx</literal> commands to
        change <link linkend="app-psql-meta-commands">\pset</link> output
        options for the duration of that single command (Tom Lane)
       </para>

       <para>
        This feature allows syntax like <literal>\g (expand=on)</literal>,
        which is equivalent to <literal>\gx</literal>.
       </para>
      </listitem>

      <listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
2020-03-08 [b0b5e20cd] Show opclass and opfamily related information in psql
-->

       <para>
        Add <application>psql</application> commands to display operator
        classes and operator families (Sergey Cherkashin, Nikita Glukhov,
        Alexander Korotkov)
       </para>

       <para>
        The new commands are <link
        linkend="app-psql-meta-commands"><literal>\dAc</literal></link>,
        <literal>\dAf</literal>, <literal>\dAo</literal>,
        and <literal>\dAp</literal>.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-07-03 [9a2ea6183] Show table persistence in psql's \dt+ and related comman
-->

       <para>
        Show table persistence in <application>psql</application>'s <link
        linkend="app-psql-meta-commands"><literal>\dt+</literal></link>
        and related commands (David Fetter)
       </para>

       <para>
        In verbose mode, the table/index/view shows if the object is permanent,
        temporary, or unlogged.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-07-23 [eb5472da9] Improve psql's \d output for TOAST tables.
-->

       <para>
        Improve output of <application>psql</application>'s <link
        linkend="app-psql-meta-commands"><literal>\d</literal></link>
        for <acronym>TOAST</acronym> tables (Justin Pryzby)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-11-22 [d1c866e57] Make psql redisplay the query buffer after \e.
-->

       <para>
        Fix redisplay after <application>psql</application>'s <link
        linkend="app-psql-meta-commands"><literal>\e</literal></link>
        command (Tom Lane)
       </para>

       <para>
        When exiting the editor, if the query doesn't end with a semicolon
        or <literal>\g</literal>, the query buffer contents will now be
        displayed.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-07-05 [02e95a504] Add \warn command to psql.
-->

       <para>
        Add <link
        linkend="app-psql-meta-commands"><literal>\warn</literal></link>
        command to <application>psql</application> (David Fetter)
       </para>

       <para>
        This is like <literal>\echo</literal> except that the text is sent
        to stderr instead of stdout.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-02-28 [1933ae629] Add PostgreSQL home page to - -help output
-->

       <para>
        Add the <productname>PostgreSQL</productname> home page to command-line
        <option>--help</option> output (Peter Eisentraut)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

    <sect4>
     <title><link linkend="pgbench"><application>pgbench</application></link></title>

     <itemizedlist>

      <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2019-10-03 [b1c1aa531] pgbench: add - -partitions and - -partition-method options
-->

       <para>
        Allow pgbench to partition its <quote>accounts</quote> table
        (Fabien Coelho)
       </para>

       <para>
        This allows performance testing of partitioning.
       </para>
      </listitem>

      <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-04-03 [9d8ef9880] Add support for \aset in pgbench
-->

       <para>
        Add pgbench command <literal>\aset</literal>, which behaves
        like <literal>\gset</literal>, but for multiple queries (Fabien
        Coelho)
       </para>
      </listitem>

      <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-11-06 [a386942bd] Add "G" (server-side data generation) as an initializati
-->

       <para>
        Allow pgbench to generate its initial data server-side, rather
        than client-side (Fabien Coelho)
       </para>
      </listitem>

      <listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
2019-07-16 [5823677ac] Provide pgbench - -show-script to dump built-in scripts.
-->

       <para>
        Allow pgbench to show script contents using option
        <option>--show-script</option> (Fabien Coelho)
       </para>
      </listitem>

     </itemizedlist>

    </sect4>

   </sect3>

   <sect3>
    <title>Server Applications</title>

    <itemizedlist>

     <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
2020-04-03 [0d8c9c121] Generate backup manifests for base backups, and validate
Author: Robert Haas <rhaas@postgresql.org>
2020-04-12 [dbc60c559] Rename pg_validatebackup to pg_verifybackup.
-->

      <para>
       Generate backup manifests for base backups, and verify them (Robert
       Haas)
      </para>

      <para>
       A new tool <link
       linkend="app-pgverifybackup"><application>pg_verifybackup</application></link>
       can verify backups.
      </para>
     </listitem>

     <listitem>
<!--
Author: Author: Fujii Masao <fujii@postgresql.org>
2020-03-19 [fab13dc50] Make pg_basebackup ask the server to estimate the total
-->

      <para>
       Have <link
       linkend="app-pgbasebackup"><application>pg_basebackup</application></link>
       estimate the total backup size by default (Fujii Masao)
      </para>

      <para>
       This computation allows <link
       linkend="monitoring-stats-dynamic-views-table"><structname>pg_stat_progress_basebackup</structname></link>
       to show progress.  If that is not needed, it can be disabled by
       using the <option>--no-estimate-size</option> option.  Previously,
       this computation happened only if the <option>--progress</option>
       option was used.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-09-30 [927474ce1] pg_rewind: Allow writing recovery configuration
-->

      <para>
       Add an option to <link
       linkend="app-pgrewind"><application>pg_rewind</application></link>
       to configure standbys (Paul Guo, Jimmy Yih, Ashwin Agrawal)
      </para>

      <para>
       This matches <link
       linkend="app-pgbasebackup"><application>pg_basebackup</application></link>'s
       <option>--write-recovery-conf</option> option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-04-01 [a7e8ece41] Add -c/- -restore-target-wal to pg_rewind
-->

      <para>
       Allow <application>pg_rewind</application> to use the target
       cluster's <xref linkend="guc-restore-command"/> to retrieve needed
       <acronym>WAL</acronym> (Alexey Kondratov)
      </para>

      <para>
       This is enabled using the
       <option>-c</option>/<option>--restore-target-wal</option> option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2019-09-27 [5adafaf17] Have pg_rewind run crash recovery before rewinding
-->

      <para>
       Have <application>pg_rewind</application> automatically run crash
       recovery before rewinding (Paul Guo, Jimmy Yih, Ashwin Agrawal)
      </para>

      <para>
       This can be disabled by using <option>--no-ensure-shutdown</option>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2019-11-13 [7b8a899bd] Make pg_waldump report more detail information about PRE
-->

      <para>
       Increase the <link linkend="sql-prepare-transaction"><command>PREPARE
       TRANSACTION</command></link>-related information reported by
       <application>pg_waldump</application> (Fujii Masao)
      </para>
     </listitem>

     <listitem>
<!--
Author: Robert Haas <rhaas@postgresql.org>
2020-04-02 [ac44367ef] pg_waldump: Add a - -quiet option.
-->

      <para>
       Add <link
       linkend="pgwaldump"><application>pg_waldump</application></link>
       option <option>--quiet</option> to suppress non-error output (Andres
       Freund, Robert Haas)
      </para>
     </listitem>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-03-25 [2f9eb3132] pg_dump: Allow dumping data of specific foreign servers
-->

      <para>
       Add <link
       linkend="app-pgdump"><application>pg_dump</application></link>
       option <option>--include-foreign-data</option> to dump data from
       foreign servers (Luis Carril)
      </para>
     </listitem>

     <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2020-01-29 [47bc9ced0] Add - -parallel option to vacuumdb command.
-->

      <para>
       Allow vacuum commands run by <link
       linkend="app-vacuumdb">vacuumdb</link> to operate in parallel mode
       (Masahiko Sawada)
      </para>

      <para>
       This is enabled with the new <option>--parallel</option> option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2019-07-27 [5ab892c39] Add support for - -jobs in reindexdb
-->

      <para>
       Allow <link linkend="app-reindexdb">reindexdb</link> to operate in
       parallel (Julien Rouhaud)
      </para>

      <para>
       Parallel mode is enabled with the new <option>--jobs</option> option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
2019-11-20 [80e05a088] Add the support for '-f' option in dropdb utility.
-->

      <para>
       Allow <link linkend="app-dropdb">dropdb</link> to disconnect
       sessions using the target database, allowing the drop to succeed
       (Pavel Stehule)
      </para>

      <para>
       This is enabled with the <option>-f</option> option.
      </para>
     </listitem>

     <listitem>
<!--
Author: Author: Michael Paquier <michael@paquier.xyz>
2019-10-23 [4fa5edcd1] Remove last traces of - -adduser/- -no-adduser in createus
-->

      <para>
       Remove <option>--adduser</option> and <option>--no-adduser</option>
       from <link linkend="app-createuser">createuser</link> (Alexander
       Lakhin)
      </para>

      <para>
       The long-supported preferred options for this are called
       <option>--superuser</option> and <option>--no-superuser</option>.
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-07-27 [959f6d6a1] pg_upgrade: Default new bindir to pg_upgrade location
-->

      <para>
       Use the directory of the <link
       linkend="pgupgrade"><application>pg_upgrade</application></link>
       program as the default <option>--new-bindir</option> setting when
       running <application>pg_upgrade</application> (Daniel Gustafsson)
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Documentation</title>

    <itemizedlist>

     <listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
2020-04-03 [347d2b07f] Add a glossary to the documentation
-->

      <para>
       Add a <link linkend="glossary">glossary</link> to the documentation
       (Corey Huinker, J&uuml;rgen Purtz, Roger Harkavy, &Aacute;lvaro
       Herrera)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-12 [e894c6183] Doc: introduce new layout for tables of functions and op
-->

      <para>
       Reformat tables containing <link linkend="functions">function
       and operator information</link> for better clarity (Tom Lane)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-08-13 [416c75cf3] Update to DocBook 4.5
-->

      <para>
       Upgrade to use <link linkend="docguide-docbook">DocBook 4.5</link>
       (Peter Eisentraut)
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Source Code</title>

    <itemizedlist>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2019-07-02 [2b1394fc2] Add support for Visual Studio 2019 in build scripts
-->

      <para>
       Add support for building on Visual Studio 2019 (Haribabu Kommi)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-12-19 [e975c1a60] Add support for MSYS2
-->

      <para>
       Add build support for MSYS2 (Peter Eisentraut)
      </para>
     </listitem>

     <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
2019-10-18 [30ee5d17c] For all ppc compilers, implement compare_exchange and fe
-->

      <para>
       Add compare_exchange and fetch_add assembly language code for Power
       PC compilers (Noah Misch)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-07-04 [7b925e127] Sync our Snowball stemmer dictionaries with current upst
-->

      <para>
       Update <link linkend="textsearch-snowball-dictionary">Snowball
       stemmer</link> dictionaries used by full text search (Panagiotis
       Mavrogiorgos)
      </para>

      <para>
       This adds Greek stemming and improves Danish and French stemming.
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-02-19 [e2e02191e] Clean up some code, comments and docs referring to Windo
-->

      <para>
       Remove support for Windows 2000 (Michael Paquier)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-07-01 [c72f9b950] Remove support for non-ELF BSD systems
-->

      <para>
       Remove support for non-<acronym>ELF</acronym> <acronym>BSD</acronym>
       systems (Peter Eisentraut)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-01-08 [37f21ed13] Remove support for Python older than 2.6
-->

      <para>
       Remove <link linkend="plpython">support</link> for Python versions
       2.5.X and earlier (Peter Eisentraut)
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2020-01-06 [7b283d0e1] Remove support for OpenSSL 0.9.8 and 1.0.0
-->

      <para>
       Remove <link linkend="install-short">support</link> for OpenSSL 0.9.8
       and 1.0.0 (Michael Paquier)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-11-27 [4513d8b07] Move configure - -disable-float8-byval to pg_config_manua
Author: Peter Eisentraut <peter@eisentraut.org>
2019-11-21 [2e4db241b] Remove configure - -disable-float4-byval
-->

      <para>
       Remove <link linkend="install-short">configure</link> options
       <option>--disable-float8-byval</option>
       and <option>--disable-float4-byval</option> (Peter Eisentraut)
      </para>

      <para>
       These were needed for compatibility with some version-zero C
       functions, but those are no longer supported.
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-03-30 [6aba63ef3] Allow the planner-related functions and hook to accept t
-->

      <para>
       Pass the query string to planner hook functions (Pascal Legrand,
       Julien Rouhaud)
      </para>
     </listitem>

     <listitem>
<!--
Author: Joe Conway <mail@joeconway.com>
2019-11-23 [f7a2002e8] Add object TRUNCATE hook
-->

      <para>
       Add <link linkend="sql-truncate"><command>TRUNCATE</command></link>
       command hook (Yuli Khodorkovskiy)
      </para>
     </listitem>

     <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2020-03-25 [896fcdb23] Provide a TLS init hook
-->

      <para>
       Add <acronym>TLS</acronym> init hook (Andrew Dunstan)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2020-01-31 [a9cff89f7] Allow building without default socket directory
-->

      <para>
       Allow building with no predefined Unix-domain socket directory
       (Peter Eisentraut)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-09-05 [7de19fbc0] Use data directory inode number, not port, to select Sys
-->

      <para>
       Reduce the probability of SysV resource key collision on Unix platforms
       (Tom Lane)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
2019-09-05 [74a308cf5] Use explicit_bzero
-->

      <para>
       Use operating system functions to reliably erase memory that contains
       sensitive information (Peter Eisentraut)
      </para>

      <para>
       For example, this is used for clearing passwords stored in memory.
      </para>
     </listitem>

     <listitem>
<!--
Author: Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-08-19 [55ea10918] Add "headerscheck" script to test header-file compilabil
-->

      <para>
       Add <filename>headerscheck</filename> script to test C header-file
       compatibility (Tom Lane)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-07-15 [1cff1b95a] Represent Lists as expansible arrays, not chains of cons
-->

      <para>
       Implement internal lists as arrays, rather than a chain of cells
       (Tom Lane)
      </para>

      <para>
       This improves performance for queries that access many objects.
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-07-24 [92fe6895d] Fix assorted bugs by changing TS_execute's callback API
2020-07-24 [70eca6a9a] Replace TS_execute's TS_EXEC_CALC_NOT flag with TS_EXEC_
-->

      <para>
       Change the API for <function>TS_execute()</function> (Tom Lane,
       Pavel Borisov)
      </para>

      <para>
       <function>TS_execute</function> callbacks must now provide ternary
       (yes/no/maybe) logic.  Calculating NOT queries accurately is now
       the default.
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

   <sect3>
    <title>Additional Modules</title>

    <itemizedlist>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-01-29 [50fc694e4] Invent "trusted" extensions, and remove the pg_pltemplat
-->

      <para>
       Allow <link linkend="sql-createextension">extensions</link> to be
       specified as trusted (Tom Lane)
      </para>

      <para>
       Such extensions can be installed in a database by users with
       database-level <literal>CREATE</literal> privileges, even if they
       are not superusers.  This change also removes
       the <structname>pg_pltemplate</structname> system catalog.
      </para>
     </listitem>

     <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2019-12-20 [6136e94dc] Superuser can permit passwordless connections on postgre
-->

      <para>
       Allow non-superusers to connect to <xref linkend="postgres-fdw"/>
       foreign servers without using a password (Craig Ringer)
      </para>

      <para>
       Specifically, allow a superuser to set
       <literal>password_required</literal> to false for
       a <link linkend="sql-alterusermapping">user mapping</link>.  Care
       must still be taken to prevent non-superusers from using superuser
       credentials to connect to the foreign server.
      </para>
     </listitem>

     <listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2020-01-09 [f5fd995a1] Allow 'sslkey' and 'sslcert' in postgres_fdw user mappin
-->

      <para>
       Allow <application>postgres_fdw</application> to use certificate
       authentication (Craig Ringer)
      </para>

      <para>
       Different users can use different certificates.
      </para>
     </listitem>

     <listitem>
<!--
Author: Joe Conway <mail@joeconway.com>
2019-11-23 [4f66c93f6] Update sepgsql to add mandatory access control for TRUNC
-->

      <para>
       Allow <xref linkend="sepgsql"/> to control access to the
       <command>TRUNCATE</command> command (Yuli Khodorkovskiy)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-06 [36058a3c5] Create contrib/bool_plperl to provide a bool transform f
-->

      <para>
       Add extension <link
       linkend="plperl"><application>bool_plperl</application></link>
       which transforms <acronym>SQL</acronym> booleans to/from PL/Perl
       booleans (Ivan Panchenko)
      </para>
     </listitem>

     <listitem>
<!--
Author: Andrew Gierth <rhodiumtoad@postgresql.org>
2019-07-14 [6e74c64bc] Teach pg_stat_statements not to ignore FOR UPDATE clause
-->

      <para>
       Have <xref linkend="pgstatstatements"/> treat <command>SELECT
       ... FOR UPDATE</command> commands as distinct from those
       without <command>FOR UPDATE</command> (Andrew Gierth, Vik Fearing)
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-04-02 [17e032822] Allow pg_stat_statements to track planning statistics.
2020-07-03 [8d459762b] Change default of pg_stat_statements.track_planning to o
-->

      <para>
       Allow <application>pg_stat_statements</application> to optionally
       track the planning time of statements (Julien Rouhaud, Pascal Legrand,
       Thomas Munro, Fujii Masao)
      </para>

      <para>
       Previously only execution time was tracked.
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-31 [70dc4c509] Fix lquery's NOT handling, and add ability to quantify n
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-01 [17ca06799] Clean up parsing of ltree and lquery some more.
-->

      <para>
       Overhaul <xref linkend="ltree"/>'s lquery syntax to treat
       <literal>NOT</literal> (!) more logically (Filip Rembialkowski,
       Tom Lane, Nikita Glukhov)
      </para>

      <para>
       Also allow non-* queries to use a numeric range ({}) of matches.
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-04-01 [949a9f043] Add support for binary I/O of ltree, lquery, and ltxtque
-->

      <para>
       Add support for binary I/O of <xref linkend="ltree"/>, lquery, and
       ltxtquery types (Nino Floris)
      </para>
     </listitem>

     <listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2020-03-08 [806eb92c0] Add an "absval" parameter to allow contrib/dict_int to i
-->

      <para>
       Add an option to <xref linkend="dict-int"/> to ignore the sign
       of integers (Jeff Janes)
      </para>
     </listitem>

     <listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
2020-01-24 [d694e0bb7] Add pg_file_sync() to adminpack extension.
-->

      <para>
       Add <xref linkend="adminpack"/> function
       <function>pg_file_sync()</function> to allow fsync'ing a file
       (Fujii Masao)
      </para>
     </listitem>

     <listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
2019-09-12 [ddbd5d873] Add to pageinspect function to make t_infomask/t_infomas
Author: Author: Michael Paquier <michael@paquier.xyz>
2019-09-19 [58b4cb30a] Redesign pageinspect function printing infomask bits
-->

      <para>
       Add <xref linkend="pageinspect"/> functions to output
       <structfield>t_infomask</structfield>/<structfield>t_infomask2</structfield>
       values in human-readable format (Craig Ringer, Sawada Masahiko,
       Michael Paquier)
      </para>
     </listitem>

     <listitem>
<!--
Author: Peter Geoghegan <pg@bowt.ie>
2020-02-29 [93ee38ead] Teach pageinspect about nbtree deduplication.
-->

      <para>
       Add B-tree index de-duplication processing columns to pageinspect output
       (Peter Geoghegan)
      </para>
     </listitem>

    </itemizedlist>

   </sect3>

  </sect2>

  <sect2 id="release-13-acknowledgements">
   <title>Acknowledgments</title>

   <para>
    The following individuals (in alphabetical order) have contributed to this
    release as patch authors, committers, reviewers, testers, or reporters of
    issues.
   </para>

   <simplelist>
    <member>Abhijit Menon-Sen</member>
    <member>Adam Lee</member>
    <member>Adam Scott</member>
    <member>Adé Heyward</member>
    <member>Adrien Nayrat</member>
    <member>Ahsan Hadi</member>
    <member>Alastair McKinley</member>
    <member>Aleksandr Parfenov</member>
    <member>Alex Aktsipetrov</member>
    <member>Alex Macy</member>
    <member>Alex Shulgin</member>
    <member>Alexander Korotkov</member>
    <member>Alexander Kukushkin</member>
    <member>Alexander Kuzmenkov</member>
    <member>Alexander Lakhin</member>
    <member>Alexey Bashtanov</member>
    <member>Alexey Kondratov</member>
    <member>Álvaro Herrera</member>
    <member>Amit Kapila</member>
    <member>Amit Khandekar</member>
    <member>Amit Langote</member>
    <member>Amul Sul</member>
    <member>Anastasia Lubennikova</member>
    <member>Andreas Joseph Krogh</member>
    <member>Andreas Karlsson</member>
    <member>Andreas Kunert</member>
    <member>Andreas Seltenreich</member>
    <member>Andrei Zubkov</member>
    <member>Andres Freund</member>
    <member>Andrew Bille</member>
    <member>Andrew Dunstan</member>
    <member>Andrew Gierth</member>
    <member>Andrey Borodin</member>
    <member>Andrey Klychkov</member>
    <member>Andrey Lepikhov</member>
    <member>Anna Akenteva</member>
    <member>Anna Endo</member>
    <member>Anthony Nowocien</member>
    <member>Anton Vlasov</member>
    <member>Antonin Houska</member>
    <member>Ants Aasma</member>
    <member>Arne Roland</member>
    <member>Arnold Müller</member>
    <member>Arseny Sher</member>
    <member>Arthur Nascimento</member>
    <member>Arthur Zakirov</member>
    <member>Ashutosh Bapat</member>
    <member>Ashutosh Sharma</member>
    <member>Ashwin Agrawal</member>
    <member>Asif Rehman</member>
    <member>Asim Praveen</member>
    <member>Atsushi Torikoshi</member>
    <member>Augustinas Jokubauskas</member>
    <member>Austin Drenski</member>
    <member>Basil Bourque</member>
    <member>Beena Emerson</member>
    <member>Ben Cornett</member>
    <member>Benjie Gillam</member>
    <member>Benoît Lobréau</member>
    <member>Bernd Helmle</member>
    <member>Bharath Rupireddy</member>
    <member>Bhargav Kamineni</member>
    <member>Binguo Bao</member>
    <member>Brad DeJong</member>
    <member>Brandur Leach</member>
    <member>Brent Bates</member>
    <member>Brian Williams</member>
    <member>Bruce Momjian</member>
    <member>Cameron Ezell</member>
    <member>Cary Huang</member>
    <member>Chapman Flack</member>
    <member>Charles Offenbacher</member>
    <member>Chen Huajun</member>
    <member>Chenyang Lu</member>
    <member>Chris Bandy</member>
    <member>Chris Travers</member>
    <member>Christoph Berg</member>
    <member>Christophe Courtois</member>
    <member>Corey Huinker</member>
    <member>Craig Ringer</member>
    <member>Cuiping Lin</member>
    <member>Dagfinn Ilmari Mannsåker</member>
    <member>Daniel Fiori</member>
    <member>Daniel Gustafsson</member>
    <member>Daniel Vérité</member>
    <member>Daniel Westermann</member>
    <member>Darafei Praliaskouski</member>
    <member>Daryl Waycott</member>
    <member>Dave Cramer</member>
    <member>David Christensen</member>
    <member>David Fetter</member>
    <member>David G. Johnston</member>
    <member>David Gilman</member>
    <member>David Harper</member>
    <member>David Rowley</member>
    <member>David Steele</member>
    <member>David Zhang</member>
    <member>Davinder Singh</member>
    <member>Dean Rasheed</member>
    <member>Denis Stuchalin</member>
    <member>Dent John</member>
    <member>Didier Gautheron</member>
    <member>Dilip Kumar</member>
    <member>Dmitry Belyavsky</member>
    <member>Dmitry Dolgov</member>
    <member>Dmitry Ivanov</member>
    <member>Dmitry Telpt</member>
    <member>Dmitry Uspenskiy</member>
    <member>Dominik Czarnota</member>
    <member>Dongming Liu</member>
    <member>Ed Morley</member>
    <member>Edmund Horner</member>
    <member>Emre Hasegeli</member>
    <member>Eric Gillum</member>
    <member>Erik Rijkers</member>
    <member>Erwin Brandstetter</member>
    <member>Ethan Waldo</member>
    <member>Etsuro Fujita</member>
    <member>Eugen Konkov</member>
    <member>Euler Taveira</member>
    <member>Fabien Coelho</member>
    <member>Fabrízio de Royes Mello</member>
    <member>Felix Lechner</member>
    <member>Filip Janus</member>
    <member>Filip Rembialkowski</member>
    <member>Frank Gagnepain</member>
    <member>Georgios Kokolatos</member>
    <member>Gilles Darold</member>
    <member>Greg Nancarrow</member>
    <member>Grigory Smolkin</member>
    <member>Guancheng Luo</member>
    <member>Guillaume Lelarge</member>
    <member>Hadi Moshayedi</member>
    <member>Haiying Tang</member>
    <member>Hamid Akhtar</member>
    <member>Hans Buschmann</member>
    <member>Hao Wu</member>
    <member>Haribabu Kommi</member>
    <member>Haruka Takatsuka</member>
    <member>Heath Lord</member>
    <member>Heikki Linnakangas</member>
    <member>Himanshu Upadhyaya</member>
    <member>Hironobu Suzuki</member>
    <member>Hugh McMaster</member>
    <member>Hugh Ranalli</member>
    <member>Hugh Wang</member>
    <member>Ian Barwick</member>
    <member>Ibrar Ahmed</member>
    <member>Ildar Musin</member>
    <member>Insung Moon</member>
    <member>Ireneusz Pluta</member>
    <member>Isaac Morland</member>
    <member>Ivan Kartyshov</member>
    <member>Ivan Panchenko</member>
    <member>Ivan Sergio Borgonovo</member>
    <member>Jaime Casanova</member>
    <member>James Coleman</member>
    <member>James Gray</member>
    <member>James Hunter</member>
    <member>James Inform</member>
    <member>James Lucas</member>
    <member>Jan Mussler</member>
    <member>Jaroslav Sivy</member>
    <member>Jeevan Chalke</member>
    <member>Jeevan Ladhe</member>
    <member>Jeff Davis</member>
    <member>Jeff Janes</member>
    <member>Jehan-Guillaume de Rorthais</member>
    <member>Jeremy Evans</member>
    <member>Jeremy Schneider</member>
    <member>Jeremy Smith</member>
    <member>Jerry Sievers</member>
    <member>Jesper Pedersen</member>
    <member>Jesse Kinkead</member>
    <member>Jesse Zhang</member>
    <member>Jian Zhang</member>
    <member>Jie Zhang</member>
    <member>Jim Nasby</member>
    <member>Jimmy Yih</member>
    <member>Jobin Augustine</member>
    <member>Joe Conway</member>
    <member>John Hsu</member>
    <member>John Naylor</member>
    <member>Jon Jensen</member>
    <member>Jonathan Katz</member>
    <member>Jorge Gustavo Rocha</member>
    <member>Josef Šimánek</member>
    <member>Joseph Nahmias</member>
    <member>Juan José Santamaría Flecha</member>
    <member>Julian Backes</member>
    <member>Julien Rouhaud</member>
    <member>Jürgen Purtz</member>
    <member>Justin King</member>
    <member>Justin Pryzby</member>
    <member>Karl O. Pinc</member>
    <member>Keisuke Kuroda</member>
    <member>Keith Fiske</member>
    <member>Kelly Min</member>
    <member>Ken Tanzer</member>
    <member>Kirill Bychik</member>
    <member>Kirk Jamison</member>
    <member>Konstantin Knizhnik</member>
    <member>Kuntal Ghosh</member>
    <member>Kyle Kingsbury</member>
    <member>Kyotaro Horiguchi</member>
    <member>Lars Kanis</member>
    <member>Laurenz Albe</member>
    <member>Leif Gunnar Erlandsen</member>
    <member>Li Japin</member>
    <member>Liudmila Mantrova</member>
    <member>Lucas Viecelli</member>
    <member>Luis M. Carril</member>
    <member>Lukáš Sobotka</member>
    <member>Maciek Sakrejda</member>
    <member>Magnus Hagander</member>
    <member>Mahadevan Ramachandran</member>
    <member>Mahendra Singh Thalor</member>
    <member>Manuel Rigger</member>
    <member>Marc Munro</member>
    <member>Marcos David</member>
    <member>Marina Polyakova</member>
    <member>Mark Dilger</member>
    <member>Mark Wong</member>
    <member>Marko Tiikkaja</member>
    <member>Markus Winand</member>
    <member>Marti Raudsepp</member>
    <member>Martijn van Oosterhout</member>
    <member>Masahiko Sawada</member>
    <member>Masahiro Ikeda</member>
    <member>Masao Fujii</member>
    <member>Mateusz Guzik</member>
    <member>Matt Jibson</member>
    <member>Matteo Beccati</member>
    <member>Maxence Ahlouche</member>
    <member>Melanie Plageman</member>
    <member>Michael Banck</member>
    <member>Michael Luo</member>
    <member>Michael Meskes</member>
    <member>Michael Paquier</member>
    <member>Michail Nikolaev</member>
    <member>Mike Palmiotto</member>
    <member>Mithun Cy</member>
    <member>Movead Li</member>
    <member>Nathan Bossart</member>
    <member>Nazli Ugur Koyluoglu</member>
    <member>Neha Sharma</member>
    <member>Nicola Contu</member>
    <member>Nicolás Alvarez</member>
    <member>Nikhil Sontakke</member>
    <member>Nikita Glukhov</member>
    <member>Nikolay Shaplov</member>
    <member>Nino Floris</member>
    <member>Noah Misch</member>
    <member>Noriyoshi Shinoda</member>
    <member>Oleg Bartunov</member>
    <member>Oleg Samoilov</member>
    <member>Oleksii Kliukin</member>
    <member>Ondrej Jirman</member>
    <member>Panagiotis Mavrogiorgos</member>
    <member>Pascal Legrand</member>
    <member>Patrick McHardy</member>
    <member>Paul Guo</member>
    <member>Paul Jungwirth</member>
    <member>Paul Ramsey</member>
    <member>Paul Sivash</member>
    <member>Paul Spencer</member>
    <member>Pavan Deolasee</member>
    <member>Pavel Borisov</member>
    <member>Pavel Luzanov</member>
    <member>Pavel Stehule</member>
    <member>Pavel Suderevsky</member>
    <member>Peifeng Qiu</member>
    <member>Pengzhou Tang</member>
    <member>Peter Billen</member>
    <member>Peter Eisentraut</member>
    <member>Peter Geoghegan</member>
    <member>Peter Smith</member>
    <member>Petr Fedorov</member>
    <member>Petr Jelínek</member>
    <member>Phil Bayer</member>
    <member>Philip Semanchuk</member>
    <member>Philippe Beaudoin</member>
    <member>Pierre Ducroquet</member>
    <member>Pierre Giraud</member>
    <member>Piotr Gabriel Kosinski</member>
    <member>Piotr Wlodarczyk</member>
    <member>Prabhat Sahu</member>
    <member>Quan Zongliang</member>
    <member>Quentin Rameau</member>
    <member>Rafael Castro</member>
    <member>Rafia Sabih</member>
    <member>Raj Mohite</member>
    <member>Rajkumar Raghuwanshi</member>
    <member>Ramanarayana M</member>
    <member>Ranier Vilela</member>
    <member>Rares Salcudean</member>
    <member>Raúl Marín Rodríguez</member>
    <member>Raymond Martin</member>
    <member>Reijo Suhonen</member>
    <member>Richard Guo</member>
    <member>Robert Ford</member>
    <member>Robert Haas</member>
    <member>Robert Kahlert</member>
    <member>Robert Treat</member>
    <member>Robin Abbi</member>
    <member>Robins Tharakan</member>
    <member>Roger Harkavy</member>
    <member>Roman Peshkurov</member>
    <member>Rui DeSousa</member>
    <member>Rui Hai Jiang</member>
    <member>Rushabh Lathia</member>
    <member>Ryan Lambert</member>
    <member>Ryohei Takahashi</member>
    <member>Scott Ribe</member>
    <member>Sean Farrell</member>
    <member>Sehrope Sarkuni</member>
    <member>Sergei Agalakov</member>
    <member>Sergei Kornilov</member>
    <member>Sergey Cherkashin</member>
    <member>Shawn Debnath</member>
    <member>Shawn Wang</member>
    <member>Shay Rojansky</member>
    <member>Shenhao Wang</member>
    <member>Simon Riggs</member>
    <member>Slawomir Chodnicki</member>
    <member>Soumyadeep Chakraborty</member>
    <member>Stéphane Lorek</member>
    <member>Stephen Frost</member>
    <member>Steve Rogerson</member>
    <member>Steven Winfield</member>
    <member>Surafel Temesgen</member>
    <member>Suraj Kharage</member>
    <member>Takanori Asaba</member>
    <member>Takao Fujii</member>
    <member>Takayuki Tsunakawa</member>
    <member>Takuma Hoshiai</member>
    <member>Tatsuhito Kasahara</member>
    <member>Tatsuo Ishii</member>
    <member>Tatsuro Yamada</member>
    <member>Taylor Vesely</member>
    <member>Teodor Sigaev</member>
    <member>Tham Nguyen</member>
    <member>Thibaut Madelaine</member>
    <member>Thom Brown</member>
    <member>Thomas Kellerer</member>
    <member>Thomas Munro</member>
    <member>Tiago Anastacio</member>
    <member>Tim Clarke</member>
    <member>Tim Möhlmann</member>
    <member>Tom Ellis</member>
    <member>Tom Gottfried</member>
    <member>Tom Lane</member>
    <member>Tomas Vondra</member>
    <member>Tuomas Leikola</member>
    <member>Tushar Ahuja</member>
    <member>Victor Wagner</member>
    <member>Victor Yegorov</member>
    <member>Vignesh C</member>
    <member>Vik Fearing</member>
    <member>Vinay Banakar</member>
    <member>Vladimir Leskov</member>
    <member>Vladimir Sitnikov</member>
    <member>Vyacheslav Makarov</member>
    <member>Vyacheslav Shablistyy</member>
    <member>Will Leinweber</member>
    <member>William Crowell</member>
    <member>Wyatt Alt</member>
    <member>Yang Xiao</member>
    <member>Yaroslav Schekin</member>
    <member>Yi Huang</member>
    <member>Yigong Hu</member>
    <member>Yoann La Cancellera</member>
    <member>Yoshikazu Imai</member>
    <member>Yu Kimura</member>
    <member>Yugo Nagata</member>
    <member>Yuli Khodorkovskiy</member>
    <member>Yusuke Egashira</member>
    <member>Yuya Watari</member>
    <member>Yuzuko Hosoya</member>
    <member>ZhenHua Cai</member>
   </simplelist>
  </sect2>

 </sect1>