]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Release notes for 18.4, 17.10, 16.14, 15.18, 14.23.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 10 May 2026 16:07:32 +0000 (12:07 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 10 May 2026 16:07:32 +0000 (12:07 -0400)
doc/src/sgml/release-16.sgml

index f737a7ead22519e136d364a05015a5006beafaba..40bcb9ed66739dfce08c6c55e8cfcf43970f9cf5 100644 (file)
@@ -1,6 +1,951 @@
 <!-- doc/src/sgml/release-16.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-16-14">
+  <title>Release 16.14</title>
+
+  <formalpara>
+  <title>Release date:</title>
+  <para>2026-05-14</para>
+  </formalpara>
+
+  <para>
+   This release contains a variety of fixes from 16.13.
+   For information about new features in major release 16, see
+   <xref linkend="release-16"/>.
+  </para>
+
+  <sect2 id="release-16-14-migration">
+   <title>Migration to Version 16.14</title>
+
+   <para>
+    A dump/restore is not required for those running 16.X.
+   </para>
+
+   <para>
+    However, if you are upgrading from a version earlier than 16.10,
+    see <xref linkend="release-16-10"/>.
+   </para>
+  </sect2>
+
+  <sect2 id="release-16-14-changes">
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [f76686ce7] 2026-05-01 11:13:50 +0900
+Branch: REL_18_STABLE [e8fd5e579] 2026-05-01 11:16:36 +0900
+Branch: master [ba82de48e] 2026-05-08 10:57:50 +0900
+Branch: REL_18_STABLE [1132af22c] 2026-05-08 10:59:13 +0900
+Branch: master [a1b754558] 2026-05-08 12:45:51 +0900
+Branch: REL_18_STABLE [5c214b58b] 2026-05-08 12:47:26 +0900
+Branch: master [5a55ea507] 2026-05-05 10:22:53 +0900
+Branch: REL_18_STABLE [b62f514ac] 2026-05-05 10:26:17 +0900
+Branch: REL_17_STABLE [d0e73bb18] 2026-05-05 10:28:24 +0900
+Branch: REL_16_STABLE [748fe9e60] 2026-05-05 10:30:37 +0900
+Branch: REL_15_STABLE [872c9fae7] 2026-05-05 10:32:25 +0900
+Branch: REL_14_STABLE [8395446df] 2026-05-05 10:33:47 +0900
+Branch: master [574581b50] 2026-05-05 10:23:31 +0900
+Branch: REL_18_STABLE [bed3ffbf9] 2026-05-05 10:27:06 +0900
+Branch: REL_17_STABLE [13226050e] 2026-05-05 10:29:01 +0900
+Branch: REL_16_STABLE [5a24cef08] 2026-05-05 10:31:17 +0900
+Branch: REL_15_STABLE [bab4f7fa5] 2026-05-05 10:32:42 +0900
+Branch: REL_14_STABLE [172034f6e] 2026-05-05 10:34:07 +0900
+-->
+     <para>
+      Check for nondeterministic collations before assuming that an
+      equality condition on a collatable type implies uniqueness
+      (Richard Guo)
+      <ulink url="&commit_baseurl;748fe9e60">&sect;</ulink>
+      <ulink url="&commit_baseurl;5a24cef08">&sect;</ulink>
+     </para>
+
+     <para>
+      Numerous planner optimizations assume that, for example, at most one
+      table row can satisfy <literal>WHERE x = 'abc'</literal> if there is
+      a unique index on <literal>x</literal>.  However this conclusion is
+      unsafe in general if the index and the <literal>WHERE</literal>
+      clause have different collations attached.  It is safe when both
+      collations are deterministic, because that property essentially
+      requires that equality of two strings means bitwise equality.  But
+      nondeterministic collations don't act that way, so that optimizing
+      on the assumption of unique matches can give wrong query answers if
+      either the <literal>WHERE</literal> clause or the index has a
+      nondeterministic collation.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [cfcd57111] 2026-04-20 14:48:23 -0400
+Branch: REL_18_STABLE [16fb94605] 2026-04-20 14:48:23 -0400
+Branch: REL_17_STABLE [766d40286] 2026-04-20 14:48:23 -0400
+Branch: REL_16_STABLE [d509be4ac] 2026-04-20 14:48:23 -0400
+Branch: master [f0ac6d494] 2026-04-20 19:24:52 -0400
+Branch: REL_17_STABLE [53cb4ec1d] 2026-04-20 19:24:46 -0400
+Branch: REL_16_STABLE [798dabe83] 2026-04-20 19:24:46 -0400
+-->
+     <para>
+      Fix incomplete removal of relation references
+      in <literal>RestrictInfo</literal> structs during join removal
+      (Tom Lane)
+      <ulink url="&commit_baseurl;d509be4ac">&sect;</ulink>
+      <ulink url="&commit_baseurl;798dabe83">&sect;</ulink>
+     </para>
+
+     <para>
+      This oversight has been shown to result in planner failures such as
+      unexpected <quote>FULL JOIN is only supported with merge-joinable or
+      hash-joinable join conditions</quote> errors.  It may also have
+      caused failure to consider valid plans in other cases.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [c6a79be3f] 2026-04-21 14:28:26 +0900
+Branch: REL_18_STABLE [e528bfe97] 2026-04-21 14:29:33 +0900
+Branch: REL_17_STABLE [9d6208939] 2026-04-21 14:31:15 +0900
+Branch: REL_16_STABLE [07b257189] 2026-04-21 14:33:07 +0900
+Branch: REL_15_STABLE [7062bd577] 2026-04-21 14:33:57 +0900
+Branch: REL_14_STABLE [8e39951be] 2026-04-21 14:35:43 +0900
+-->
+     <para>
+      Fix incorrect handling of <literal>NEW</literal> generated columns
+      in rule actions and rule qualifications (Richard Guo, Dean Rasheed)
+      <ulink url="&commit_baseurl;07b257189">&sect;</ulink>
+     </para>
+
+     <para>
+      Previously, such column references would produce NULL
+      in <literal>INSERT</literal> cases, or be equivalent to
+      the <literal>OLD</literal> value in <literal>UPDATE</literal> cases.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: REL_18_STABLE [11c2c0cc8] 2026-04-06 14:22:17 -0400
+Branch: REL_17_STABLE [681a91d29] 2026-04-06 14:22:17 -0400
+Branch: REL_16_STABLE [3c7a6bbe6] 2026-04-06 14:22:17 -0400
+Branch: REL_15_STABLE [07e833e3c] 2026-04-06 14:22:17 -0400
+Branch: REL_14_STABLE [40fa04e7c] 2026-04-06 14:22:17 -0400
+-->
+     <para>
+      Fix spurious <quote>generated columns are not supported in COPY FROM
+      WHERE conditions</quote> errors (Tom Lane)
+      <ulink url="&commit_baseurl;3c7a6bbe6">&sect;</ulink>
+     </para>
+
+     <para>
+      Use of a system column in a <literal>COPY FROM WHERE</literal>
+      condition could sometimes incorrectly report this error.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alexander Korotkov <akorotkov@postgresql.org>
+Branch: master [177037341] 2026-03-05 19:49:28 +0200
+Branch: REL_18_STABLE [13fab378e] 2026-03-05 19:50:06 +0200
+Branch: REL_17_STABLE [2dcac93c0] 2026-03-05 19:56:42 +0200
+Branch: REL_16_STABLE [f6e63d4b8] 2026-03-05 20:02:08 +0200
+Branch: REL_15_STABLE [8bfaae6fb] 2026-03-05 19:57:32 +0200
+-->
+     <para>
+      Correctly report a serialization failure
+      when <command>MERGE</command> encounters a concurrently-updated
+      tuple in repeatable-read or serializable mode (Tender Wang)
+      <ulink url="&commit_baseurl;f6e63d4b8">&sect;</ulink>
+     </para>
+
+     <para>
+      Previously, such cases behaved the same as in lower isolation
+      levels.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [6cf49e804] 2026-04-30 11:04:57 -0400
+Branch: REL_18_STABLE [149c875fc] 2026-04-30 11:05:29 -0400
+Branch: REL_17_STABLE [a0104b447] 2026-04-30 11:14:37 -0400
+Branch: REL_16_STABLE [7bb519635] 2026-04-30 11:14:26 -0400
+Branch: REL_15_STABLE [76d15a7ee] 2026-04-30 11:14:12 -0400
+Branch: REL_14_STABLE [81b56b47c] 2026-04-30 11:13:50 -0400
+-->
+     <para>
+      Fix <literal>CREATE TABLE ... LIKE ... INCLUDING
+      STATISTICS</literal> for cases where the source table has dropped
+      column(s) (Julien Tachoires)
+      <ulink url="&commit_baseurl;7bb519635">&sect;</ulink>
+     </para>
+
+     <para>
+      In such cases, extended statistics objects could be copied
+      incorrectly, or the command could give an incorrect error.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [9d3e094f1] 2026-04-22 10:32:10 +0900
+Branch: REL_18_STABLE [5713ac248] 2026-04-22 10:34:33 +0900
+Branch: REL_17_STABLE [becf6d269] 2026-04-22 10:34:35 +0900
+Branch: REL_16_STABLE [313355d68] 2026-04-22 10:34:37 +0900
+Branch: REL_15_STABLE [0859000d0] 2026-04-22 10:34:38 +0900
+Branch: REL_14_STABLE [d809b16d1] 2026-04-22 10:34:40 +0900
+-->
+     <para>
+      Allow <literal>ALTER INDEX ... ATTACH PARTITION</literal> to mark
+      the parent index valid if appropriate (Sami Imseih)
+      <ulink url="&commit_baseurl;313355d68">&sect;</ulink>
+     </para>
+
+     <para>
+      There are edge cases in which a partitioned index might remain
+      marked as invalid even when all its leaf indexes are valid.  This
+      change provides a mechanism whereby a user can correct such a
+      situation without resorting to manual catalog updates.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [703fee3b2] 2026-03-19 15:07:43 -0700
+Branch: REL_18_STABLE [c11f87b1a] 2026-03-19 14:59:30 -0700
+Branch: REL_17_STABLE [876fa84a2] 2026-03-19 15:02:18 -0700
+Branch: REL_16_STABLE [a19edb66a] 2026-03-19 15:00:58 -0700
+Branch: REL_15_STABLE [3a35ab1d0] 2026-03-19 15:01:22 -0700
+Branch: REL_14_STABLE [c6f369e58] 2026-03-19 15:01:45 -0700
+-->
+     <para>
+      Fix <command>ALTER FOREIGN DATA WRAPPER</command> to not drop the
+      wrapper object's dependency on its handler function (Jeff Davis)
+      <ulink url="&commit_baseurl;a19edb66a">&sect;</ulink>
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [dd4069197] 2026-04-23 21:28:11 +0300
+Branch: REL_18_STABLE [ff8f27d6e] 2026-04-23 21:28:59 +0300
+Branch: REL_17_STABLE [54343f6f9] 2026-04-23 21:31:32 +0300
+Branch: REL_16_STABLE [06e304524] 2026-04-23 21:33:02 +0300
+Branch: REL_15_STABLE [34ebeb15c] 2026-04-23 21:33:25 +0300
+Branch: REL_14_STABLE [c7a1d5fc6] 2026-04-23 21:33:39 +0300
+-->
+     <para>
+      Disallow making a composite type be a member of itself via a
+      multirange (Heikki Linnakangas)
+      <ulink url="&commit_baseurl;06e304524">&sect;</ulink>
+     </para>
+
+     <para>
+      We already forbade such cases when the intermediate type is a
+      domain, array, composite type, or range; but multiranges were
+      overlooked.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [0d866282b] 2026-03-30 16:14:34 +1300
+Branch: REL_18_STABLE [49315de0c] 2026-03-30 16:16:09 +1300
+Branch: REL_17_STABLE [d29808e35] 2026-03-30 16:16:39 +1300
+Branch: REL_16_STABLE [1bd90c887] 2026-03-30 16:17:14 +1300
+Branch: REL_15_STABLE [6b2e091f0] 2026-03-30 16:17:39 +1300
+Branch: REL_14_STABLE [6ce5c310b] 2026-03-30 16:18:13 +1300
+-->
+     <para>
+      Fix datum-image comparisons to be insensitive to sign-extension
+      variations (David Rowley)
+      <ulink url="&commit_baseurl;1bd90c887">&sect;</ulink>
+     </para>
+
+     <para>
+      This fixes some situations that previously led to <quote>could not
+      find memoization table entry</quote> errors or wrong query results.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [94219a73f] 2026-04-24 14:03:12 +1200
+Branch: REL_18_STABLE [035c520db] 2026-04-24 14:03:41 +1200
+Branch: REL_17_STABLE [3fda3e12f] 2026-04-24 14:04:05 +1200
+Branch: REL_16_STABLE [a2a0060d5] 2026-04-24 14:04:31 +1200
+Branch: REL_15_STABLE [622f8b530] 2026-04-24 14:04:55 +1200
+Branch: REL_14_STABLE [109de35b7] 2026-04-24 14:05:23 +1200
+-->
+     <para>
+      Fix incorrect logic for hashed <literal>IN</literal>/<literal>NOT
+      IN</literal> with non-strict equality operator (Chengpeng Yan)
+      <ulink url="&commit_baseurl;a2a0060d5">&sect;</ulink>
+     </para>
+
+     <para>
+      The previous coding could crash or give wrong answers.  All built-in
+      data types have strict equality operators, so that this issue could
+      only arise with an extension data type.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [a50777680] 2026-04-22 12:41:00 -0400
+Branch: REL_18_STABLE [580e7be88] 2026-04-22 12:41:00 -0400
+Branch: REL_17_STABLE [c97a28618] 2026-04-22 12:41:00 -0400
+Branch: REL_16_STABLE [e1e60f148] 2026-04-22 12:41:01 -0400
+Branch: REL_15_STABLE [f60d25986] 2026-04-22 12:41:01 -0400
+Branch: REL_14_STABLE [8a6f08c0c] 2026-04-22 12:41:01 -0400
+-->
+     <para>
+      Truncate overly-long locale-specific numeric symbols
+      in <function>to_char()</function> (Tom Lane)
+      <ulink url="&commit_baseurl;e1e60f148">&sect;</ulink>
+     </para>
+
+     <para>
+      If a locale specified a currency symbol, thousands separator, or
+      decimal or sign symbol more than 8 bytes long, a buffer overrun was
+      possible.  No such locales exist in the real world, and it's
+      impractical for an unprivileged attacker to install a malicious
+      locale definition underneath a Postgres server; but for safety's
+      sake check for overlength symbols and truncate if needed.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [d7970e7e9] 2026-04-22 12:02:15 -0400
+Branch: REL_18_STABLE [00c6e0819] 2026-04-22 12:02:15 -0400
+Branch: REL_17_STABLE [ea5f0d176] 2026-04-22 12:02:15 -0400
+Branch: REL_16_STABLE [42383d32d] 2026-04-22 12:02:15 -0400
+Branch: REL_15_STABLE [0b196d3db] 2026-04-22 12:02:15 -0400
+Branch: REL_14_STABLE [21a24d709] 2026-04-22 12:02:15 -0400
+Branch: master [844bb90d4] 2026-04-22 10:47:56 -0400
+Branch: REL_18_STABLE [c2bfeb3bb] 2026-04-22 11:04:35 -0400
+Branch: REL_17_STABLE [a5426dbf8] 2026-04-22 11:05:51 -0400
+Branch: REL_16_STABLE [17f72e037] 2026-04-22 11:06:47 -0400
+Branch: REL_15_STABLE [f852c9093] 2026-04-22 11:09:02 -0400
+Branch: REL_14_STABLE [6cae0c2bd] 2026-04-22 11:09:21 -0400
+-->
+     <para>
+      Prevent buffer overruns when parsing an affix file for
+      an <literal>Ispell</literal> dictionary (Tom Lane)
+      <ulink url="&commit_baseurl;42383d32d">&sect;</ulink>
+      <ulink url="&commit_baseurl;17f72e037">&sect;</ulink>
+     </para>
+
+     <para>
+      A corrupt or malicious affix file could crash the server.
+      This is not considered a security issue because text search
+      configuration files are presumed trustworthy, but it still seems
+      worth fixing.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [8b6c89e37] 2026-04-09 19:28:33 +0900
+Branch: REL_18_STABLE [bfc7dff26] 2026-04-09 19:30:37 +0900
+Branch: REL_17_STABLE [f8736f8bc] 2026-04-09 19:32:09 +0900
+Branch: REL_16_STABLE [0fe032e6a] 2026-04-09 19:34:02 +0900
+Branch: REL_15_STABLE [4da71fc37] 2026-04-09 19:35:08 +0900
+Branch: REL_14_STABLE [305cf0df0] 2026-04-09 19:36:13 +0900
+-->
+     <para>
+      Guard against integer overflow in calculations of frame start and
+      end positions for window aggregates (Richard Guo)
+      <ulink url="&commit_baseurl;0fe032e6a">&sect;</ulink>
+     </para>
+
+     <para>
+      Very large user-specified offsets (close to INT64_MAX) could result
+      in errors or incorrect query results.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [6582010c8] 2026-04-06 13:14:53 -0400
+Branch: REL_18_STABLE [14bf2c39e] 2026-04-06 13:14:50 -0400
+Branch: REL_17_STABLE [d6c9432cb] 2026-04-06 13:14:50 -0400
+Branch: REL_16_STABLE [bb959269e] 2026-04-06 13:14:50 -0400
+-->
+     <para>
+      Fix <function>array_agg_array_combine()</function> to combine the
+      arrays' null bitmaps correctly (Dmytro Astapov)
+      <ulink url="&commit_baseurl;bb959269e">&sect;</ulink>
+     </para>
+
+     <para>
+      This mistake resulted in sometimes-incorrect output from
+      parallelized <function>array_agg(anyarray)</function> calculations.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [5941e7f09] 2026-04-30 18:44:38 +0900
+Branch: REL_18_STABLE [6cb307251] 2026-04-30 18:44:41 +0900
+Branch: REL_17_STABLE [5499be332] 2026-04-30 18:44:43 +0900
+Branch: REL_16_STABLE [3b35c10a4] 2026-04-30 18:44:45 +0900
+-->
+     <para>
+      Retry <function>sync_file_range()</function> if it returns error
+      code <literal>EINTR</literal> (DaeMyung Kang)
+      <ulink url="&commit_baseurl;3b35c10a4">&sect;</ulink>
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [80156cee0] 2026-04-11 17:02:52 +0900
+Branch: REL_18_STABLE [b081c5b07] 2026-04-11 17:03:04 +0900
+Branch: REL_17_STABLE [a4fefb3e0] 2026-04-11 17:03:06 +0900
+Branch: REL_16_STABLE [c7cdcbd3e] 2026-04-11 17:03:08 +0900
+Branch: REL_15_STABLE [c6d3f0585] 2026-04-11 17:03:10 +0900
+-->
+     <para>
+      Fix incorrect behavior
+      of <function>pg_stat_reset_single_table_counters()</function> on a
+      shared catalog (Chao Li)
+      <ulink url="&commit_baseurl;c7cdcbd3e">&sect;</ulink>
+     </para>
+
+     <para>
+      Such cases had a side-effect of resetting the
+      current database's <literal>stat_reset_timestamp</literal>, which
+      was unintended.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [090c4297e] 2026-04-20 10:31:11 +0530
+Branch: REL_18_STABLE [44c8dc280] 2026-04-20 10:23:22 +0530
+Branch: REL_17_STABLE [88d7fdcc9] 2026-04-20 10:17:47 +0530
+Branch: REL_16_STABLE [d052f6c7d] 2026-04-20 10:13:55 +0530
+-->
+     <para>
+      Update activity statistics when a parallel apply worker is idle
+      (Zhijie Hou)
+      <ulink url="&commit_baseurl;d052f6c7d">&sect;</ulink>
+     </para>
+
+     <para>
+      Previously, statistics from a recently-completed transaction might
+      go unreported for long intervals, particularly if the workload is
+      light.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [2b5ba2a0a] 2026-04-10 07:13:08 -0400
+Branch: REL_18_STABLE [c3e436b1c] 2026-04-10 10:28:00 -0400
+Branch: REL_17_STABLE [c05c3baf1] 2026-04-10 10:27:43 -0400
+Branch: REL_16_STABLE [e630f65d0] 2026-04-10 10:27:16 -0400
+Branch: REL_15_STABLE [c88ad3a21] 2026-04-10 10:26:50 -0400
+Branch: REL_14_STABLE [de32a01e7] 2026-04-10 10:22:48 -0400
+-->
+     <para>
+      Fix buffer overread when <function>pglz_decompress()</function>
+      receives corrupt input (Andrew Dunstan)
+      <ulink url="&commit_baseurl;e630f65d0">&sect;</ulink>
+     </para>
+
+     <para>
+      It was possible to read a few bytes past the end of the input, which
+      in very unlucky cases might cause a crash.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [739477345] 2026-03-30 13:59:58 -0400
+Branch: REL_18_STABLE [adb7873bb] 2026-03-30 13:59:54 -0400
+Branch: REL_17_STABLE [1f5b6a5e5] 2026-03-30 13:59:54 -0400
+Branch: REL_16_STABLE [59c139d53] 2026-03-30 13:59:54 -0400
+Branch: REL_15_STABLE [811f3263a] 2026-03-30 13:59:54 -0400
+Branch: REL_14_STABLE [7cd23aad2] 2026-03-30 13:59:54 -0400
+-->
+     <para>
+      Ensure that tuplestore data structures are internally consistent
+      even after an error (Tom Lane)
+      <ulink url="&commit_baseurl;59c139d53">&sect;</ulink>
+     </para>
+
+     <para>
+      The code was previously careless about this, which is fine most of
+      the time but is problematic for the tuplestore backing
+      a <literal>WITH HOLD</literal> cursor.  In v15 and before this
+      leads to easily-reproducible crashes; later branches are not known
+      to be vulnerable, but it seems best to preserve consistency in all.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [eef1ba704] 2026-03-26 20:49:31 +0900
+Branch: REL_18_STABLE [98e96e579] 2026-03-26 20:50:22 +0900
+Branch: REL_17_STABLE [fdce5de55] 2026-03-26 20:50:27 +0900
+Branch: REL_16_STABLE [f42105001] 2026-03-26 20:50:33 +0900
+Branch: REL_15_STABLE [246c296f0] 2026-03-26 20:50:38 +0900
+Branch: REL_14_STABLE [bf7ecf353] 2026-03-26 20:50:43 +0900
+-->
+     <para>
+      Fix premature NULL lag reporting
+      in <structname>pg_stat_replication</structname> (Shinya Kato)
+      <ulink url="&commit_baseurl;f42105001">&sect;</ulink>
+     </para>
+
+     <para>
+      The lag columns frequently read as NULL even while replication
+      activity was happening.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tomas Vondra <tomas.vondra@postgresql.org>
+Branch: master [b1f14c967] 2026-03-13 23:25:24 +0100
+Branch: REL_18_STABLE [5b3f63a1b] 2026-03-13 23:26:02 +0100
+Branch: REL_17_STABLE [6ef36bb35] 2026-03-13 23:26:15 +0100
+Branch: REL_16_STABLE [4f4025eac] 2026-03-13 23:26:25 +0100
+Branch: REL_15_STABLE [ce06b5740] 2026-03-13 23:26:36 +0100
+Branch: REL_14_STABLE [c0ffc725f] 2026-03-13 23:26:49 +0100
+-->
+     <para>
+      Avoid rare flush failure when working with non-WAL-logged GiST
+      indexes (Tomas Vondra)
+      <ulink url="&commit_baseurl;4f4025eac">&sect;</ulink>
+     </para>
+
+     <para>
+      A non-logged GiST index could nonetheless sometimes
+      produce <quote>xlog flush request <replaceable>n/nnnn</replaceable>
+      is not satisfied</quote> errors, due to incorrect selection of
+      a <quote>fake LSN</quote> to represent an insertion point.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [4da2afd01] 2026-03-09 13:46:27 +0900
+Branch: REL_18_STABLE [a0f38604d] 2026-03-09 13:46:31 +0900
+Branch: REL_17_STABLE [2543b9ea9] 2026-03-09 13:46:33 +0900
+Branch: REL_16_STABLE [0af5e64e9] 2026-03-09 13:46:35 +0900
+Branch: REL_15_STABLE [46c93b705] 2026-03-09 13:46:37 +0900
+Branch: REL_14_STABLE [eb11d7a91] 2026-03-09 13:46:38 +0900
+-->
+     <para>
+      Fix underestimate of required size of DSA page maps for odd-size
+      segments (Paul Bunn)
+      <ulink url="&commit_baseurl;0af5e64e9">&sect;</ulink>
+     </para>
+
+     <para>
+      This miscalculation led to out-of-bounds accesses and hence server
+      crashes.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [3b7a6fa15] 2026-03-02 09:38:37 +0900
+Branch: REL_18_STABLE [83671c0da] 2026-03-02 09:38:40 +0900
+Branch: REL_17_STABLE [530b6b02f] 2026-03-02 09:38:42 +0900
+Branch: REL_16_STABLE [04745ba9c] 2026-03-02 09:38:44 +0900
+Branch: REL_15_STABLE [f033abc6c] 2026-03-02 09:38:46 +0900
+Branch: REL_14_STABLE [038c7d4a3] 2026-03-02 09:38:47 +0900
+-->
+     <para>
+      Fix possible server crash when processing extended statistics on
+      expressions of extension data types (Michael Paquier)
+      <ulink url="&commit_baseurl;04745ba9c">&sect;</ulink>
+     </para>
+
+     <para>
+      NULL pointer dereferences were possible if the data type's
+      typanalyze function does not compute any useful statistics.
+      No in-core typanalyze function behaves that way, but extensions
+      could.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [d942511f0] 2026-02-26 12:15:01 -0800
+Branch: REL_18_STABLE [4abf63c62] 2026-02-26 12:15:15 -0800
+Branch: REL_17_STABLE [4761f2eee] 2026-02-26 12:15:23 -0800
+Branch: REL_16_STABLE [a4515c9b4] 2026-02-26 12:15:31 -0800
+-->
+     <para>
+      Fix minor memory leaks in ICU-based string processing (Jeff Davis)
+      <ulink url="&commit_baseurl;a4515c9b4">&sect;</ulink>
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [9b43e6793] 2026-04-21 09:39:59 +0900
+Branch: REL_18_STABLE [affdb2dd5] 2026-04-21 09:40:03 +0900
+Branch: REL_17_STABLE [e381843cf] 2026-04-21 09:40:04 +0900
+Branch: REL_16_STABLE [2d347f2cd] 2026-04-21 09:40:06 +0900
+Branch: REL_15_STABLE [23cebf672] 2026-04-21 09:40:07 +0900
+-->
+     <para>
+      If the startup process fails, properly shut down other child
+      processes before exiting the postmaster (Ayush Tiwari)
+      <ulink url="&commit_baseurl;2d347f2cd">&sect;</ulink>
+     </para>
+
+     <para>
+      The handling of this situation relied on a long-obsolete assumption
+      that no other postmaster children exist while the startup process is
+      running, so that immediate postmaster exit is acceptable.
+      Orphaned children would eventually notice the postmaster's death and
+      exit on their own, but a cleaner shutdown procedure is desirable.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: REL_18_STABLE [0852643e1] 2026-03-23 11:53:32 +0200
+Branch: REL_17_STABLE [1ca385032] 2026-03-23 11:59:07 +0200
+Branch: REL_16_STABLE [77dff5d93] 2026-03-23 12:02:27 +0200
+Branch: REL_15_STABLE [a5f412107] 2026-03-23 12:02:35 +0200
+Branch: REL_14_STABLE [e35e466f6] 2026-03-23 12:03:30 +0200
+-->
+     <para>
+      Fix race condition between WAL replay of checkpoints and multixact
+      ID creations (Heikki Linnakangas)
+      <ulink url="&commit_baseurl;77dff5d93">&sect;</ulink>
+     </para>
+
+     <para>
+      A standby server following WAL from a primary of an older minor
+      version could get into a crash-and-restart loop complaining
+      about <quote>could not access status of transaction</quote>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [6eedb2a5f] 2026-03-06 16:43:40 +0900
+Branch: REL_18_STABLE [3eb2fecdb] 2026-03-06 16:44:40 +0900
+Branch: REL_17_STABLE [bbbc0888b] 2026-03-06 16:44:45 +0900
+Branch: REL_16_STABLE [82935467a] 2026-03-06 16:44:51 +0900
+Branch: REL_15_STABLE [42734f296] 2026-03-06 16:44:59 +0900
+Branch: REL_14_STABLE [3bf6f22ce] 2026-03-06 16:45:05 +0900
+Branch: master [d927b4bd9] 2026-03-17 08:10:20 +0900
+Branch: REL_18_STABLE [980498138] 2026-03-17 08:12:25 +0900
+Branch: REL_17_STABLE [8ee536c89] 2026-03-17 08:12:32 +0900
+Branch: REL_16_STABLE [da21ecf57] 2026-03-17 08:12:37 +0900
+Branch: REL_15_STABLE [fa9f2e317] 2026-03-17 08:12:41 +0900
+Branch: REL_14_STABLE [f15471464] 2026-03-17 08:12:46 +0900
+-->
+     <para>
+      Prevent indefinite wait in shutdown of a walsender process
+      (Anthonin Bonnefoy)
+      <ulink url="&commit_baseurl;82935467a">&sect;</ulink>
+      <ulink url="&commit_baseurl;da21ecf57">&sect;</ulink>
+     </para>
+
+     <para>
+      At shutdown of a cluster that is publishing logical replication
+      data, the walsender waits for all pending WAL to be written out.
+      But it did not correctly request that to happen, so that in some
+      cases this could become an indefinite wait.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alexander Korotkov <akorotkov@postgresql.org>
+Branch: master [c06d1a4ba] 2026-05-03 20:23:50 +0300
+Branch: REL_18_STABLE [ac3b97db3] 2026-05-03 20:27:36 +0300
+Branch: REL_17_STABLE [1cf010f21] 2026-05-03 20:27:33 +0300
+Branch: REL_16_STABLE [54537de35] 2026-05-03 20:27:02 +0300
+Branch: REL_15_STABLE [ca259b084] 2026-05-03 20:26:55 +0300
+Branch: REL_14_STABLE [f5d1038d9] 2026-05-03 20:26:07 +0300
+-->
+     <para>
+      Ensure that changes to tables' free space maps are persisted during
+      recovery (Alexey Makhmutov)
+      <ulink url="&commit_baseurl;54537de35">&sect;</ulink>
+     </para>
+
+     <para>
+      Previously, while WAL replay did update the free space map while
+      replaying operations that should change it, the map page buffer did
+      not get marked dirty if checksums are enabled, so that the changes
+      might never get written out.  On a standby server, over time this
+      would result in a map wildly at variance with the table's actual
+      contents.  While the map is only used as a hint, this condition
+      could cause significant performance degradation for some period of
+      time after the standby server is promoted to be active, until most
+      of the map has been repaired by updates.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [c34a280c8] 2026-05-01 15:12:28 -0400
+Branch: REL_18_STABLE [e2688ea5e] 2026-05-01 15:15:15 -0400
+Branch: REL_17_STABLE [5d67549d9] 2026-05-01 15:15:23 -0400
+Branch: REL_16_STABLE [7e4c871f4] 2026-05-01 15:15:33 -0400
+Branch: REL_15_STABLE [6916f4410] 2026-05-01 15:16:02 -0400
+Branch: REL_14_STABLE [f0e3f9732] 2026-05-01 15:16:42 -0400
+-->
+     <para>
+      Fix crashes in some <application>ecpg</application> functions when
+      called without any established connection (Shruthi Gowda)
+      <ulink url="&commit_baseurl;7e4c871f4">&sect;</ulink>
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [01d58d7e3] 2026-03-29 09:01:47 -0400
+Branch: REL_18_STABLE [5095f3f4a] 2026-03-29 09:02:15 -0400
+Branch: REL_17_STABLE [f1298a4c2] 2026-03-29 09:11:37 -0400
+Branch: REL_16_STABLE [1590723f0] 2026-03-29 09:12:28 -0400
+Branch: REL_15_STABLE [d3bb7841b] 2026-03-29 09:12:40 -0400
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [ac0accafd] 2026-03-05 14:43:21 -0500
+Branch: REL_18_STABLE [a01a592b1] 2026-03-05 14:43:21 -0500
+Branch: REL_17_STABLE [8b198b093] 2026-03-05 14:43:21 -0500
+Branch: REL_16_STABLE [cce939c71] 2026-03-05 14:43:21 -0500
+Branch: REL_15_STABLE [9a42888a3] 2026-03-05 14:43:21 -0500
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [c70f6dc6b] 2026-03-04 12:08:37 -0500
+Branch: REL_18_STABLE [78dc9a808] 2026-03-04 12:08:37 -0500
+Branch: REL_17_STABLE [2640c5ba7] 2026-03-04 12:08:37 -0500
+Branch: REL_16_STABLE [415cc943f] 2026-03-04 12:08:37 -0500
+Branch: REL_15_STABLE [4548e8746] 2026-03-04 12:08:37 -0500
+-->
+     <para>
+      Fix assorted bugs in backup decompression and tar-parsing code
+      (Andrew Dunstan, Tom Lane, Chao Li)
+      <ulink url="&commit_baseurl;1590723f0">&sect;</ulink>
+      <ulink url="&commit_baseurl;cce939c71">&sect;</ulink>
+      <ulink url="&commit_baseurl;415cc943f">&sect;</ulink>
+     </para>
+
+     <para>
+      The decompression and tar-file reading code used
+      in <application>pg_basebackup</application>
+      and <application>pg_verifybackup</application> mishandled tar-file
+      padding data, could corrupt LZ4-compressed data in edge cases,
+      failed to check for some unusual error conditions, failed to exit
+      after compression/decompression errors (leading to cascading error
+      reports), and leaked memory.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [74b4438a7] 2026-03-02 11:15:10 -0500
+Branch: REL_18_STABLE [b09158cc7] 2026-03-02 11:14:58 -0500
+Branch: REL_17_STABLE [1cd783d20] 2026-03-02 11:14:58 -0500
+Branch: REL_16_STABLE [a4649c50a] 2026-03-02 11:14:58 -0500
+-->
+     <para>
+      In <application>pg_dumpall</application>, don't skip
+      role <literal>GRANT</literal>s with dangling grantor OIDs
+      (Tom Lane)
+      <ulink url="&commit_baseurl;a4649c50a">&sect;</ulink>
+     </para>
+
+     <para>
+      Instead, handle such cases by emitting <literal>GRANT</literal>
+      without any <literal>GRANTED BY</literal> clause, as we did before
+      v16.  This avoids losing the grant in foreseeable cases, since
+      pre-v16 servers didn't prevent dropping the grantor role.  Continue
+      to emit a warning about the missing grantor, but only if the source
+      server is v16 or later.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Jacob Champion <jchampion@postgresql.org>
+Branch: master [a60a10338] 2026-02-24 14:01:37 -0800
+Branch: REL_18_STABLE [1b2773179] 2026-02-24 14:01:41 -0800
+Branch: REL_17_STABLE [ad7fc3f1f] 2026-02-24 14:01:46 -0800
+Branch: REL_16_STABLE [a38ed212f] 2026-02-24 14:01:51 -0800
+Branch: REL_15_STABLE [e726620d2] 2026-02-24 14:01:54 -0800
+Branch: REL_14_STABLE [c47744ede] 2026-02-24 14:01:58 -0800
+-->
+     <para>
+      In <application>pg_upgrade</application>, take care to use the
+      correct protocol version when connecting to older source servers
+      (Jacob Champion)
+      <ulink url="&commit_baseurl;a38ed212f">&sect;</ulink>
+     </para>
+
+     <para>
+      This could be problematic when attempting to upgrade from a pre-2018
+      server.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master [cc774c543] 2026-03-02 13:12:25 -0600
+Branch: REL_18_STABLE [bde9ad315] 2026-03-02 13:12:25 -0600
+Branch: REL_17_STABLE [f510577de] 2026-03-02 13:12:25 -0600
+Branch: REL_16_STABLE [28c2b7896] 2026-03-02 13:12:25 -0600
+Branch: REL_15_STABLE [8fc45ac5d] 2026-03-02 13:12:25 -0600
+-->
+     <para>
+      In <filename>contrib/basic_archive</filename>, allow the archive
+      directory to be missing at startup (Nathan Bossart)
+      <ulink url="&commit_baseurl;28c2b7896">&sect;</ulink>
+     </para>
+
+     <para>
+      Previously, the setting
+      of <literal>basic_archive.archive_directory</literal> was rejected
+      if it didn't point to an existing directory.  This is undesirable
+      because archiving will be stuck indefinitely, even if the directory
+      appears later.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [c8308a984] 2026-02-26 12:23:22 -0800
+Branch: REL_18_STABLE [b3c2a3d38] 2026-02-26 12:23:51 -0800
+Branch: REL_18_STABLE [53a57cae1] 2026-02-26 15:19:31 -0800
+Branch: REL_17_STABLE [d1bd9a7dc] 2026-02-26 12:24:12 -0800
+Branch: REL_16_STABLE [3ed2c7ef7] 2026-02-26 12:25:00 -0800
+Branch: REL_15_STABLE [2b993167f] 2026-02-26 12:26:13 -0800
+Branch: REL_14_STABLE [058710d41] 2026-02-26 12:26:32 -0800
+-->
+     <para>
+      Fix <filename>contrib/ltree</filename> to cope when case-folding
+      changes a string's byte length (Jeff Davis)
+      <ulink url="&commit_baseurl;3ed2c7ef7">&sect;</ulink>
+     </para>
+
+     <para>
+      Previously, <type>lquery</type> patterns specifying case-insensitive
+      matching might fail to match labels they should match.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [3c74cb576] 2026-03-27 12:25:10 +0200
+Branch: REL_18_STABLE [25b02320e] 2026-03-27 12:21:29 +0200
+Branch: REL_17_STABLE [351e59f34] 2026-03-27 12:21:38 +0200
+Branch: REL_16_STABLE [52edaf9d9] 2026-03-27 12:21:48 +0200
+Branch: REL_15_STABLE [92cf11171] 2026-03-27 12:22:21 +0200
+Branch: REL_14_STABLE [a6d03067f] 2026-03-27 12:23:38 +0200
+-->
+     <para>
+      In <filename>contrib/pg_stat_statements</filename>, don't leak
+      memory if an error occurs while parsing the
+      <filename>pgss_query_texts.stat</filename> file (Heikki Linnakangas)
+      <ulink url="&commit_baseurl;52edaf9d9">&sect;</ulink>
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Etsuro Fujita <efujita@postgresql.org>
+Branch: master [648818ba3] 2026-05-05 18:55:00 +0900
+Branch: REL_18_STABLE [c318777da] 2026-05-05 18:55:02 +0900
+Branch: REL_17_STABLE [af8f9248f] 2026-05-05 18:55:03 +0900
+Branch: REL_16_STABLE [1352651c2] 2026-05-05 18:55:04 +0900
+Branch: REL_15_STABLE [34c18a225] 2026-05-05 18:55:05 +0900
+Branch: REL_14_STABLE [fd5b36ab1] 2026-05-05 18:55:06 +0900
+-->
+     <para>
+      In <filename>contrib/postgres_fdw</filename>, avoid crash due to
+      premature cleanup of a failed connection (Etsuro Fujita)
+      <ulink url="&commit_baseurl;1352651c2">&sect;</ulink>
+     </para>
+
+     <para>
+      If a remote connection fails abort cleanup, we can't use it any
+      longer.  But delay closing the connection object until end of
+      transaction, because there might still be references to it within
+      data structures such as open cursors.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [f64f62f5b] 2026-04-24 12:28:35 -0400
+Branch: REL_18_STABLE [8a431b6d6] 2026-04-24 12:28:35 -0400
+Branch: REL_17_STABLE [4c0eab6f0] 2026-04-24 12:28:35 -0400
+Branch: REL_16_STABLE [0465c999e] 2026-04-24 12:28:35 -0400
+Branch: REL_15_STABLE [e28fc73d5] 2026-04-24 12:28:35 -0400
+Branch: REL_14_STABLE [affd929c9] 2026-04-24 12:28:35 -0400
+-->
+     <para>
+      Update time zone data files to <application>tzdata</application>
+      release 2026b (Tom Lane)
+      <ulink url="&commit_baseurl;0465c999e">&sect;</ulink>
+     </para>
+
+     <para>
+      British Columbia (America/Vancouver) will be on year-round UTC-07
+      (effectively, permanent DST) beginning in November 2026.  This
+      release assumes that their TZ abbreviation will
+      be <literal>MST</literal> from that time forward.  That seems likely
+      to change, but it's unclear what new abbreviation will be used.
+      Also a historical correction for Moldova: they have followed EU DST
+      transition times since 2022.
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-16-13">
   <title>Release 16.13</title>