From ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 2 Aug 2024 16:24:17 -0400
Subject: [PATCH] First-draft release notes for 16.4.

As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.
---
 doc/src/sgml/release-16.sgml | 1239 ++++++++++++++++++++++++++++++++++
 1 file changed, 1239 insertions(+)

diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml
index 54860aa0e1d..69eee35eedc 100644
--- a/doc/src/sgml/release-16.sgml
+++ b/doc/src/sgml/release-16.sgml
@@ -1,6 +1,1245 @@
 <!-- doc/src/sgml/release-16.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-16-4">
+  <title>Release 16.4</title>
+
+  <formalpara>
+  <title>Release date:</title>
+  <para>2024-08-08</para>
+  </formalpara>
+
+  <para>
+   This release contains a variety of fixes from 16.3.
+   For information about new features in major release 16, see
+   <xref linkend="release-16"/>.
+  </para>
+
+  <sect2 id="release-16-4-migration">
+   <title>Migration to Version 16.4</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.3,
+    see <xref linkend="release-16-3"/>.
+   </para>
+  </sect2>
+
+  <sect2 id="release-16-4-changes">
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [0ffc0acaf] 2024-07-08 10:11:46 +0900
+Branch: REL_17_STABLE [cccab85c2] 2024-07-08 10:17:12 +0900
+Branch: REL_16_STABLE [507f2347e] 2024-07-08 10:30:28 +0900
+-->
+     <para>
+      Avoid incorrect results from Merge Right Anti Join plans
+      (Richard Guo)
+     </para>
+
+     <para>
+      If the inner relation is known to have unique join keys, the merge
+      could misbehave when there are duplicated join keys in the outer
+      relation.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Melanie Plageman <melanieplageman@gmail.com>
+Branch: master [83c39a1f7] 2024-07-19 12:04:00 -0400
+Branch: REL_17_STABLE [fd4f12df5] 2024-07-19 12:12:03 -0400
+Branch: REL_16_STABLE [06bf404cd] 2024-07-19 12:11:41 -0400
+Branch: REL_15_STABLE [dc6354c67] 2024-07-19 12:05:51 -0400
+Branch: REL_14_STABLE [45ce054c0] 2024-07-19 12:07:53 -0400
+-->
+     <para>
+      Prevent infinite loop in <command>VACUUM</command>
+      (Melanie Plageman)
+     </para>
+
+     <para>
+      After a disconnected standby server with an old running transaction
+      reconnected to the primary, it was possible
+      for <command>VACUUM</command> on the primary to get confused about
+      which tuples are removable, resulting in an infinite loop.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master [3dd637f3d] 2024-07-24 12:38:18 +0200
+Branch: REL_17_STABLE [2b22543a4] 2024-07-24 12:38:18 +0200
+Branch: REL_16_STABLE [084814d88] 2024-07-24 12:38:18 +0200
+Branch: REL_15_STABLE [f74fac06c] 2024-07-24 12:38:18 +0200
+Branch: REL_14_STABLE [fe1d16f66] 2024-07-24 12:38:18 +0200
+Branch: REL_13_STABLE [ed7430975] 2024-07-24 12:38:18 +0200
+Branch: REL_12_STABLE [08b6a9ecf] 2024-07-24 12:38:18 +0200
+-->
+     <para>
+      Fix failure after attaching a table as a partition, if the
+      table had previously had inheritance children
+      (&Aacute;lvaro Herrera)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master [839177913] 2024-07-12 12:54:01 +0200
+Branch: REL_17_STABLE [30ca4e1ab] 2024-07-12 12:54:01 +0200
+Branch: REL_16_STABLE [00a40e33c] 2024-07-12 12:54:01 +0200
+Branch: REL_15_STABLE [4ae09c59d] 2024-07-12 12:54:01 +0200
+Branch: REL_14_STABLE [66aaa7a71] 2024-07-12 12:54:01 +0200
+Branch: REL_13_STABLE [057482569] 2024-07-12 12:54:01 +0200
+Branch: REL_12_STABLE [d0054432d] 2024-07-12 12:54:01 +0200
+Branch: master [74e12db19] 2024-07-12 13:44:19 +0200
+Branch: REL_17_STABLE [0340eefd9] 2024-07-12 13:44:19 +0200
+Branch: REL_16_STABLE [34eb37f79] 2024-07-12 13:44:19 +0200
+Branch: REL_15_STABLE [9f0f72d89] 2024-07-12 13:44:19 +0200
+Branch: REL_14_STABLE [2f5007459] 2024-07-12 13:44:19 +0200
+Branch: REL_13_STABLE [7898a494f] 2024-07-12 13:44:19 +0200
+Branch: REL_12_STABLE [067cb6c5d] 2024-07-12 13:44:19 +0200
+-->
+     <para>
+      Fix <command>ALTER TABLE DETACH PARTITION</command> for cases
+      involving inconsistent index-based constraints
+      (&Aacute;lvaro Herrera, Tender Wang)
+     </para>
+
+     <para>
+      When a partitioned table has an index that is not associated with a
+      constraint, but a partition has an equivalent index that is, then
+      detaching the partition would misbehave, leaving the ex-partition's
+      constraint with an incorrect <structfield>coninhcount</structfield>
+      value.  This would cause trouble during any further manipulations of
+      that constraint.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master Release: REL_17_BR [27162a64b] 2024-06-24 15:56:32 +0200
+Branch: REL_16_STABLE [96105ebfe] 2024-06-24 15:56:32 +0200
+Branch: REL_15_STABLE [fb0fb0740] 2024-06-24 15:56:32 +0200
+Branch: REL_14_STABLE [66e569f50] 2024-06-24 15:56:32 +0200
+Branch: master Release: REL_17_BR [c2fab7024] 2024-06-11 11:38:45 +0200
+Branch: REL_16_STABLE [bf78abebf] 2024-06-11 11:38:45 +0200
+Branch: REL_15_STABLE [03c8cdbb7] 2024-06-11 11:38:45 +0200
+Branch: REL_14_STABLE [5dcaefc6a] 2024-06-11 11:38:45 +0200
+-->
+     <para>
+      Fix partition pruning setup during <literal>ALTER TABLE DETACH
+      PARTITION CONCURRENTLY</literal> (&Aacute;lvaro Herrera)
+     </para>
+
+     <para>
+      The executor assumed that no partition could be detached between
+      planning and execution of a query on a partitioned table.  This is
+      no longer true since the introduction of <literal>DETACH
+      PARTITION</literal>'s <literal>CONCURRENTLY</literal> option, making
+      it possible for query execution to fail transiently when that is
+      used.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [710207032] 2024-07-13 08:09:33 -0700
+Branch: REL_17_STABLE [f5bb46fb2] 2024-07-13 08:09:36 -0700
+Branch: REL_16_STABLE [e81deeefc] 2024-07-13 08:09:37 -0700
+Branch: REL_15_STABLE [2b4a2a79e] 2024-07-13 08:09:37 -0700
+Branch: REL_14_STABLE [2b415e95a] 2024-07-13 08:09:37 -0700
+-->
+     <para>
+      Correctly update a partitioned table's
+      <structname>pg_class</structname>.<structfield>reltuples</structfield>
+      field to zero after its last child partition is dropped (Noah Misch)
+     </para>
+
+     <para>
+      The first <command>ANALYZE</command> on such a partitioned table
+      must update <structfield>relhassubclass</structfield> as well, and
+      that caused the <structfield>reltuples</structfield> update to be
+      lost.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [f535f350c] 2024-05-14 20:19:20 -0400
+Branch: REL_16_STABLE [8e0e99972] 2024-05-14 20:19:20 -0400
+Branch: REL_15_STABLE [c40e78d23] 2024-05-14 20:19:20 -0400
+Branch: REL_14_STABLE [525bd1620] 2024-05-14 20:19:20 -0400
+Branch: REL_13_STABLE [e85f641b2] 2024-05-14 20:19:20 -0400
+Branch: REL_12_STABLE [70ffb27b2] 2024-05-14 20:19:20 -0400
+Branch: master Release: REL_17_BR [751598263] 2024-06-06 15:16:56 -0400
+Branch: REL_16_STABLE [bb331af4a] 2024-06-06 15:16:56 -0400
+Branch: REL_15_STABLE [5fe43d41d] 2024-06-06 15:16:56 -0400
+Branch: REL_14_STABLE [d88dcdf0f] 2024-06-06 15:16:56 -0400
+Branch: REL_13_STABLE [9de0ff91a] 2024-06-06 15:16:56 -0400
+Branch: REL_12_STABLE [4208f44c9] 2024-06-06 15:16:56 -0400
+-->
+     <para>
+      Fix handling of polymorphic output arguments for procedures
+      (Tom Lane)
+     </para>
+
+     <para>
+      The SQL <command>CALL</command> statement did not resolve the
+      correct data types for such arguments, leading to errors such
+      as <quote>cannot display a value of type anyelement</quote>, or even
+      outright crashes.  (But <command>CALL</command>
+      in <application>PL/pgSQL</application> worked correctly.)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [2dc1deaea] 2024-06-07 13:27:26 -0400
+Branch: REL_16_STABLE [0d18b8eb4] 2024-06-07 13:27:26 -0400
+Branch: REL_15_STABLE [a160e9277] 2024-06-07 13:27:26 -0400
+Branch: REL_14_STABLE [0f7d1338c] 2024-06-07 13:27:26 -0400
+Branch: REL_13_STABLE [1d4ea1376] 2024-06-07 13:27:26 -0400
+Branch: REL_12_STABLE [0be81dd71] 2024-06-07 13:27:26 -0400
+-->
+     <para>
+      Fix behavior of stable functions called from
+      a <command>CALL</command> statement's argument list (Tom Lane)
+     </para>
+
+     <para>
+      If the <command>CALL</command> is within an atomic context
+      (e.g. there's an outer transaction block), such functions were
+      passed the wrong snapshot, causing them to see stale values of rows
+      modified since the start of the outer transaction.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [a9a7c2c3e] 2024-05-22 18:22:58 -0400
+Branch: REL_16_STABLE [019ea7675] 2024-05-22 18:22:51 -0400
+-->
+     <para>
+      Fix input of ISO-8601 <quote>extended</quote> time format for
+      types <type>time</type> and <type>timetz</type> (Tom Lane)
+     </para>
+
+     <para>
+      Re-allow cases such as <literal>T12:34:56</literal>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master [22b0ccd65] 2024-07-19 11:52:32 -0500
+Branch: REL_17_STABLE [3764ee47f] 2024-07-19 11:52:32 -0500
+Branch: REL_16_STABLE [34e9dce69] 2024-07-19 11:52:32 -0500
+Branch: REL_15_STABLE [b82791c8f] 2024-07-19 11:52:32 -0500
+Branch: REL_14_STABLE [e8dfe0430] 2024-07-19 11:52:32 -0500
+Branch: REL_13_STABLE [c5321e965] 2024-07-19 11:52:32 -0500
+Branch: REL_12_STABLE [4f9628158] 2024-07-19 11:52:32 -0500
+-->
+     <para>
+      Detect integer overflow in <type>money</type> calculations
+      (Joseph Koshakow)
+     </para>
+
+     <para>
+      None of the arithmetic functions for the <type>money</type> type
+      checked for overflow before, so they would silently give wrong
+      answers for overflowing cases.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [1ff39f4ff] 2024-07-08 17:48:45 +0100
+Branch: REL_17_STABLE [7a8977d25] 2024-07-08 17:51:23 +0100
+Branch: REL_16_STABLE [f7aec8c1d] 2024-07-08 17:52:52 +0100
+Branch: REL_15_STABLE [47ca912de] 2024-07-08 17:54:22 +0100
+Branch: REL_14_STABLE [a3c0124f6] 2024-07-08 17:55:31 +0100
+Branch: REL_13_STABLE [ece296926] 2024-07-08 17:56:51 +0100
+Branch: REL_12_STABLE [8badee787] 2024-07-08 17:58:42 +0100
+-->
+     <para>
+      Fix over-aggressive clamping of the scale argument
+      in <function>round(numeric)</function>
+      and <function>trunc(numeric)</function> (Dean Rasheed)
+     </para>
+
+     <para>
+      These functions clamped their scale argument to +/-2000, but there
+      are valid use-cases for it to be larger; the functions returned
+      incorrect results in such cases.  Instead clamp to the actual
+      allowed range of type <type>numeric</type>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [b181062aa] 2024-07-28 22:22:52 +1200
+Branch: REL_17_STABLE [1e020258e] 2024-07-28 22:23:32 +1200
+Branch: REL_16_STABLE [6f6b0f193] 2024-07-28 22:23:54 +1200
+Branch: REL_15_STABLE [0a80e88d9] 2024-07-28 22:24:15 +1200
+-->
+     <para>
+      Fix result for <function>pg_size_pretty()</function> when applied to
+      the smallest possible <type>bigint</type> value (Joseph Koshakow)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master Release: REL_17_BR [3cb2f13ac] 2024-05-13 15:53:50 -0500
+Branch: REL_16_STABLE [c1664c8ee] 2024-05-13 15:54:04 -0500
+Branch: REL_15_STABLE [857d280c6] 2024-05-13 15:54:10 -0500
+Branch: REL_14_STABLE [c8714230a] 2024-05-13 15:54:14 -0500
+Branch: REL_13_STABLE [09ec5d455] 2024-05-13 15:54:18 -0500
+Branch: REL_12_STABLE [2812059d3] 2024-05-13 15:54:23 -0500
+-->
+     <para>
+      Prevent <function>pg_sequence_last_value()</function> from failing
+      on unlogged sequences on standby servers and on temporary sequences
+      of other sessions (Nathan Bossart)
+     </para>
+
+     <para>
+      Make it return NULL in these cases instead of throwing an error.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [56a829621] 2024-06-13 20:35:02 -0400
+Branch: REL_16_STABLE [086ecd12b] 2024-06-13 20:35:02 -0400
+Branch: REL_15_STABLE [df95c1ec0] 2024-06-13 20:35:03 -0400
+Branch: REL_14_STABLE [5912bf77c] 2024-06-13 20:34:43 -0400
+Branch: REL_13_STABLE [c7de5a654] 2024-06-13 20:34:43 -0400
+Branch: REL_12_STABLE [5e63a6f43] 2024-06-13 20:34:43 -0400
+-->
+     <para>
+      Fix parsing of ignored operators
+      in <function>websearch_to_tsquery()</function> (Tom Lane)
+     </para>
+
+     <para>
+      Per the manual, punctuation in the input
+      of <function>websearch_to_tsquery()</function> is ignored except for
+      the special cases of dashes and quotes.  However, parentheses and a
+      few other characters appearing immediately before
+      an <literal>or</literal> could cause <literal>or</literal> to be
+      treated as a data word, rather than as an <literal>OR</literal>
+      operator as expected.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master [991f8cf8a] 2024-07-23 21:59:02 -0500
+Branch: REL_17_STABLE [657e54a05] 2024-07-23 21:59:02 -0500
+Branch: REL_16_STABLE [a57d16865] 2024-07-23 21:59:02 -0500
+Branch: REL_15_STABLE [547dd2cbd] 2024-07-23 21:59:02 -0500
+Branch: REL_14_STABLE [670fb9f18] 2024-07-23 21:59:02 -0500
+Branch: REL_13_STABLE [6c1b71bc6] 2024-07-23 21:59:02 -0500
+Branch: REL_12_STABLE [878e8c6be] 2024-07-23 21:59:02 -0500
+-->
+     <para>
+      Detect another integer overflow case while computing new array
+      dimensions (Joseph Koshakow)
+     </para>
+
+     <para>
+      Reject applying array
+      dimensions <literal>[-2147483648:2147483647]</literal> to an empty
+      array.  This is closely related to CVE-2023-5869, but appears
+      harmless since the array still ends up empty.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [679c5084c] 2024-07-30 16:23:20 -0700
+Branch: REL_17_STABLE [10fdc67f8] 2024-07-30 16:25:03 -0700
+Branch: REL_16_STABLE [403cbd210] 2024-07-30 16:25:21 -0700
+-->
+     <para>
+      Fix unportable usage of <function>strnxfrm()</function> (Jeff Davis)
+     </para>
+
+     <para>
+      Some code paths for non-deterministic collations could fail with
+      errors like <quote>pg_strnxfrm() returned unexpected result</quote>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master Release: REL_17_BR [f9f47f0d9] 2024-06-27 19:21:06 -0700
+Branch: REL_16_STABLE [e4afd7153] 2024-06-27 19:21:10 -0700
+Branch: REL_15_STABLE [b08a4b616] 2024-06-27 19:21:11 -0700
+Branch: REL_14_STABLE [af73e37fa] 2024-06-27 19:21:12 -0700
+Branch: REL_13_STABLE [7a21306ae] 2024-06-27 19:21:13 -0700
+Branch: REL_12_STABLE [11f3815d6] 2024-06-27 19:21:13 -0700
+-->
+     <para>
+      Detect another case of a new catalog cache entry becoming stale
+      while detoasting its fields (Noah Misch)
+     </para>
+
+     <para>
+      An in-place update occurring while we expand out-of-line fields in a
+      catalog tuple could be missed, leading to a catalog cache entry that
+      lacks the in-place change but is not known to be stale.  This is
+      only possible in the <structname>pg_database</structname> catalog,
+      so the effects are narrow, but misbehavior is possible.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [220003b9b] 2024-07-20 13:40:15 -0400
+Branch: REL_17_STABLE [041a00c48] 2024-07-20 13:40:15 -0400
+Branch: REL_16_STABLE [fd958bbbd] 2024-07-20 13:40:15 -0400
+Branch: REL_15_STABLE [96953052a] 2024-07-20 13:40:15 -0400
+Branch: REL_14_STABLE [0d712ec12] 2024-07-20 13:40:15 -0400
+Branch: REL_13_STABLE [461f47948] 2024-07-20 13:40:15 -0400
+Branch: REL_12_STABLE [feca6c688] 2024-07-20 13:40:15 -0400
+-->
+     <para>
+      Correctly check updatability of view columns targeted
+      by <literal>INSERT</literal> ... <literal>DEFAULT</literal>
+      (Tom Lane)
+     </para>
+
+     <para>
+      If such a column is non-updatable, we should give an error reporting
+      that.  But the check was missed and then later code would report an
+      unhelpful error such as <quote>attribute
+      number <replaceable>N</replaceable> not found in view
+      targetlist</quote>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [f96c2c727] 2024-07-14 13:49:46 -0400
+Branch: REL_17_STABLE [cf588e10f] 2024-07-14 13:49:46 -0400
+Branch: REL_16_STABLE [8fc487614] 2024-07-14 13:49:46 -0400
+Branch: REL_15_STABLE [e7f9f44e3] 2024-07-14 13:49:46 -0400
+Branch: REL_14_STABLE [02b4f5e1f] 2024-07-14 13:49:46 -0400
+Branch: REL_13_STABLE [b020a866a] 2024-07-14 13:49:46 -0400
+Branch: REL_12_STABLE [236b225ed] 2024-07-14 13:49:46 -0400
+-->
+     <para>
+      Avoid reporting an unhelpful internal error for incorrect recursive
+      queries (Tom Lane)
+     </para>
+
+     <para>
+      Rearrange the order of error checks so that we throw an on-point
+      error when a <command>WITH RECURSIVE</command> query does not have a
+      self-reference within the second arm of
+      the <literal>UNION</literal>, but does have one self-reference in
+      some other place such as <literal>ORDER BY</literal>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master Release: REL_17_BR [f88cdb36c] 2024-06-27 19:21:05 -0700
+Branch: REL_16_STABLE [112d05570] 2024-06-27 19:21:09 -0700
+Branch: REL_15_STABLE [24561b498] 2024-06-27 19:21:10 -0700
+-->
+     <para>
+      Lock owned sequences during <literal>ALTER TABLE SET
+      LOGGED|UNLOGGED</literal> (Noah Misch)
+     </para>
+
+     <para>
+      These commands change the persistence of a table's owned sequences
+      along with the table, but they failed to acquire lock on the
+      sequences while doing so.  This could result in losing the effects
+      of concurrent <function>nextval()</function> calls.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [e6d0d16ad] 2024-06-20 14:21:36 -0400
+Branch: REL_16_STABLE [4f1966676] 2024-06-20 14:21:36 -0400
+Branch: REL_15_STABLE [1424c7abc] 2024-06-20 14:21:36 -0400
+Branch: REL_14_STABLE [88f3baa06] 2024-06-20 14:21:36 -0400
+Branch: REL_13_STABLE [9ce8ee9d3] 2024-06-20 14:21:36 -0400
+Branch: REL_12_STABLE [b0037bbef] 2024-06-20 14:21:36 -0400
+-->
+     <para>
+      Don't throw an error if a queued <literal>AFTER</literal> trigger no
+      longer exists (Tom Lane)
+     </para>
+
+     <para>
+      It's possible for a transaction to execute an operation that queues
+      a deferred <literal>AFTER</literal> trigger for later execution, and
+      then to drop the trigger before that happens.  Formerly this led to
+      weird errors such as <quote>could not find
+      trigger <replaceable>NNNN</replaceable></quote>.  It seems better to
+      silently do nothing if the trigger no longer exists at the time when
+      it would have been executed.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [76618097a] 2024-06-14 16:20:35 -0400
+Branch: REL_16_STABLE [9cf4beb9e] 2024-06-14 16:20:35 -0400
+Branch: REL_15_STABLE [1f1eedd3f] 2024-06-14 16:20:35 -0400
+Branch: REL_14_STABLE [f3f6a14ce] 2024-06-14 16:20:35 -0400
+Branch: REL_13_STABLE [198de7961] 2024-06-14 16:20:35 -0400
+Branch: REL_12_STABLE [0a39343ae] 2024-06-14 16:20:35 -0400
+-->
+     <para>
+      Fix failure to remove <structname>pg_init_privs</structname> entries
+      for column-level privileges when their table is dropped (Tom Lane)
+     </para>
+
+     <para>
+      If an extension grants some column-level privileges on a table it
+      creates, relevant catalog entries would remain behind after the
+      extension is dropped.  This was harmless until/unless the table's
+      OID was re-used for another relation, when it could interfere with
+      what <application>pg_dump</application> dumps for that relation.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [915de706d] 2024-06-11 17:57:46 -0400
+Branch: REL_16_STABLE [b188e1bf7] 2024-06-11 17:57:46 -0400
+Branch: REL_15_STABLE [1d0399b54] 2024-06-11 17:57:46 -0400
+Branch: REL_14_STABLE [096f2132c] 2024-06-11 17:57:46 -0400
+Branch: REL_13_STABLE [5e8aa32a9] 2024-06-11 17:57:46 -0400
+Branch: REL_12_STABLE [9256bf6eb] 2024-06-11 17:57:46 -0400
+-->
+     <para>
+      Fix selection of an arbiter index for <literal>ON CONFLICT</literal>
+      when the desired index has expressions or predicates (Tom Lane)
+     </para>
+
+     <para>
+      If a query using <literal>ON CONFLICT</literal> accesses the target
+      table through an updatable view, it could fail with <quote>there is
+      no unique or exclusion constraint matching the ON CONFLICT
+      specification</quote>, even though a matching index does exist.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [7ed8ce8a4] 2024-06-07 14:50:09 -0400
+Branch: REL_16_STABLE [8397f161e] 2024-06-07 14:50:09 -0400
+Branch: REL_15_STABLE [3c71cb497] 2024-06-07 14:50:09 -0400
+Branch: REL_14_STABLE [2dad0f433] 2024-06-07 14:50:09 -0400
+Branch: REL_13_STABLE [7c4ac652e] 2024-06-07 14:50:09 -0400
+Branch: REL_12_STABLE [b8efd756d] 2024-06-07 14:50:09 -0400
+-->
+     <para>
+      Refuse to modify a temporary table of another session
+      with <literal>ALTER TABLE</literal> (Tom Lane)
+     </para>
+
+     <para>
+      Permissions checks normally would prevent this case from arising,
+      but it is possible to reach it by altering a parent table whose
+      child is another session's temporary table.  Throw an error if we
+      discover that such a child table belongs to another session.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [5278668d7] 2024-05-22 17:54:17 -0400
+Branch: REL_16_STABLE [2aa90c02d] 2024-05-22 17:54:17 -0400
+Branch: REL_15_STABLE [2f3cfcf76] 2024-05-22 17:54:17 -0400
+Branch: REL_14_STABLE [1015162c3] 2024-05-22 17:54:17 -0400
+-->
+     <para>
+      Fix handling of extended statistics on expressions
+      in <literal>CREATE TABLE LIKE STATISTICS</literal> (Tom Lane)
+     </para>
+
+     <para>
+      The <literal>CREATE</literal> command failed to adjust column
+      references in statistics expressions to the possibly-different
+      column numbering of the new table.  This resulted in invalid
+      statistics objects that would cause problems later.  A typical
+      scenario where renumbering columns is needed is when the source
+      table contains some dropped columns.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [d0d44049d] 2023-07-14 11:41:20 -0400
+Branch: master Release: REL_17_BR [779ac2c74] 2024-05-18 14:26:13 -0400
+Branch: REL_16_STABLE [ce0d16544] 2024-05-18 14:31:35 -0400
+Branch: REL_15_STABLE [4ac385adc] 2024-05-18 14:31:35 -0400
+Branch: REL_14_STABLE [5ac340602] 2024-05-18 14:31:35 -0400
+Branch: REL_13_STABLE [7f90a5dc3] 2024-05-18 14:31:35 -0400
+Branch: REL_12_STABLE [686c995fc] 2024-05-18 14:31:35 -0400
+-->
+     <para>
+      Fix failure to recalculate sub-queries generated
+      from <function>MIN()</function> or <function>MAX()</function>
+      aggregates (Tom Lane)
+     </para>
+
+     <para>
+      In some cases the aggregate result computed at one row of the outer
+      query could be re-used for later rows when it should not be.  This
+      has only been seen to happen when the outer query uses
+      <literal>DISTINCT</literal> that is implemented with hash
+      aggregation, but other cases may exist.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+Branch: master Release: REL_17_BR [98b4f53d1] 2024-05-15 13:49:41 +0200
+Branch: REL_16_STABLE [315661eca] 2024-05-15 13:54:00 +0200
+-->
+     <para>
+      Re-forbid underscore in positional parameters (Erik Wienhold)
+     </para>
+
+     <para>
+      As of v16 we allow integer literals to contain underscores.
+      This change caused input such as <literal>$1_234</literal>
+      to be taken as a single token, but it did not work correctly.
+      It seems better to revert to the original definition in which a
+      parameter symbol is only <literal>$</literal> followed by digits.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [5d6c64d29] 2024-06-27 14:44:02 -0400
+Branch: REL_16_STABLE [07d66d3cc] 2024-06-27 14:44:02 -0400
+Branch: REL_15_STABLE [5401e70e4] 2024-06-27 14:44:03 -0400
+Branch: REL_14_STABLE [13abc1f66] 2024-06-27 14:44:03 -0400
+Branch: REL_13_STABLE [86fac88ee] 2024-06-27 14:44:03 -0400
+Branch: REL_12_STABLE [dccda847b] 2024-06-27 14:44:04 -0400
+-->
+     <para>
+      Avoid crashing when a JIT-inlined backend function throws an error
+      (Tom Lane)
+     </para>
+
+     <para>
+      The error state can include pointers into the dynamically loaded
+      module holding the JIT-compiled code (for error location strings).
+      In some code paths the module could get unloaded before the error
+      report is processed, leading to SIGSEGV when the location strings
+      are accessed.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [066e8ac6e] 2024-07-06 15:16:13 -0400
+Branch: master [6082b3d5d] 2024-07-08 14:04:00 -0400
+Branch: master [e7192486d] 2024-07-09 15:01:13 -0400
+Branch: master [896cd266f] 2024-07-09 16:31:24 -0400
+Branch: REL_17_STABLE [a9747be27] 2024-07-10 20:15:52 -0400
+Branch: REL_16_STABLE [f85c91a18] 2024-07-10 20:15:52 -0400
+Branch: REL_15_STABLE [f68d6aabb] 2024-07-10 20:15:52 -0400
+Branch: REL_14_STABLE [475e1807c] 2024-07-10 20:15:52 -0400
+Branch: REL_13_STABLE [48132587d] 2024-07-10 20:15:52 -0400
+Branch: REL_12_STABLE [a134baea7] 2024-07-10 20:15:52 -0400
+-->
+     <para>
+      Cope with behavioral changes in <application>libxml2</application>
+      version 2.13.x (Erik Wienhold, Tom Lane)
+     </para>
+
+     <para>
+      Notably, we now suppress <quote>chunk is not well balanced</quote>
+      errors from <application>libxml2</application>, unless that is the
+      only reported error.  This is to make error reports consistent
+      between 2.13.x and earlier <application>libxml2</application>
+      versions.  In earlier versions, that message was almost always
+      redundant or outright incorrect, so 2.13.x substantially reduced the
+      number of cases in which it's reported.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master Release: REL_17_BR [cbfbda784] 2024-06-27 21:09:58 +0300
+Branch: REL_16_STABLE [b5b418b68] 2024-06-27 21:10:27 +0300
+Branch: REL_15_STABLE [0e2f3d78b] 2024-06-27 21:10:31 +0300
+Branch: REL_14_STABLE [9dbf8ab48] 2024-06-27 21:10:34 +0300
+Branch: REL_13_STABLE [e9c8747ee] 2024-06-27 21:08:55 +0300
+Branch: REL_12_STABLE [5dea6628b] 2024-06-27 21:09:15 +0300
+-->
+     <para>
+      Fix handling of subtransactions of prepared transactions
+      when starting a hot standby server (Heikki Linnakangas)
+     </para>
+
+     <para>
+      When starting a standby's replay at a shutdown checkpoint WAL
+      record, transactions that had been prepared but not yet committed on
+      the primary are correctly understood as being still in progress.
+      But subtransactions of a prepared transaction (created by savepoints
+      or <application>PL/pgSQL</application> exception blocks) were not
+      accounted for and would be treated as aborted.  That led to
+      inconsistency if the prepared transaction was later committed.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Masahiko Sawada <msawada@postgresql.org>
+Branch: master [bb19b7008] 2024-07-11 22:48:23 +0900
+Branch: REL_17_STABLE [068674f4a] 2024-07-11 22:48:21 +0900
+Branch: REL_16_STABLE [2f3304ce1] 2024-07-11 22:48:18 +0900
+Branch: REL_15_STABLE [aee8c2b95] 2024-07-11 22:48:16 +0900
+Branch: REL_14_STABLE [f7d3caf9d] 2024-07-11 22:48:13 +0900
+Branch: REL_13_STABLE [cf2c69ec5] 2024-07-11 22:48:10 +0900
+Branch: REL_12_STABLE [1b3707587] 2024-07-11 22:48:08 +0900
+-->
+     <para>
+      Prevent incorrect initialization of logical replication slots
+      (Masahiko Sawada)
+     </para>
+
+     <para>
+      In some cases a replication slot's start point within the WAL stream
+      could be set to a point within a transaction, leading to assertion
+      failures or incorrect decoding results.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_17_BR [cd312adc5] 2024-06-06 08:47:40 +0900
+Branch: REL_16_STABLE [f2c922ff2] 2024-06-06 08:48:17 +0900
+Branch: REL_15_STABLE [bfc44da24] 2024-06-06 08:48:21 +0900
+-->
+     <para>
+      Avoid <quote>can only drop stats once</quote> error during
+      replication slot creation and drop (Floris Van Nee)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master Release: REL_17_BR [3e53492aa] 2024-06-27 11:35:00 +0530
+Branch: REL_16_STABLE [b8f953d8d] 2024-06-27 11:19:57 +0530
+Branch: REL_15_STABLE [76fda6140] 2024-06-27 10:43:52 +0530
+-->
+     <para>
+      Fix resource leakage in logical replication WAL sender (Hou Zhijie)
+     </para>
+
+     <para>
+      The walsender process leaked memory when publishing changes to a
+      partitioned table whose partitions have row types physically
+      different from the partitioned table's.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: REL_17_STABLE [31f8d620b] 2024-07-01 12:21:07 -0400
+Branch: REL_16_STABLE [54a7b21b3] 2024-07-01 12:21:07 -0400
+Branch: REL_15_STABLE [4df767cf9] 2024-07-01 12:21:07 -0400
+Branch: REL_14_STABLE [1608902fc] 2024-07-01 12:21:07 -0400
+Branch: REL_13_STABLE [5f86cd70d] 2024-07-01 12:21:07 -0400
+Branch: REL_12_STABLE [8565fb6fb] 2024-07-01 12:21:07 -0400
+-->
+     <para>
+      Avoid memory leakage after servicing a notify or sinval interrupt
+      (Tom Lane)
+     </para>
+
+     <para>
+      The processing functions for these events could switch the current
+      memory context to TopMemoryContext, resulting in session-lifespan
+      leakage of any data allocated before the incorrect setting gets
+      replaced.  There were observable leaks associated with (at least)
+      encoding conversion of incoming queries and parameters attached to
+      Bind messages.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_17_BR [7467939ea] 2024-06-27 09:44:47 +0900
+Branch: REL_16_STABLE [6f61d0e7e] 2024-06-27 09:44:51 +0900
+Branch: REL_15_STABLE [eb144dfca] 2024-06-27 09:44:55 +0900
+-->
+     <para>
+      Prevent leakage of reference counts for the shared memory block used
+      for statistics (Anthonin Bonnefoy)
+     </para>
+
+     <para>
+      A new backend process attaching to the statistics shared memory
+      incremented its reference count, but failed to decrement the count
+      when exiting.  After 2<superscript>32</superscript> sessions had
+      been created, the reference count would overflow to zero, causing
+      failures in all subsequent backend process starts.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master Release: REL_17_BR [b1ffe3ff0] 2024-06-26 23:02:06 +0300
+Branch: REL_16_STABLE [e7cbe5a85] 2024-06-26 23:04:36 +0300
+Branch: REL_15_STABLE [c809a2b2d] 2024-06-26 23:05:58 +0300
+Branch: REL_14_STABLE [4c8e00ae9] 2024-06-26 23:06:12 +0300
+-->
+     <para>
+      Prevent deadlocks and assertion failures during truncation of the
+      multixact SLRU log (Heikki Linnakangas)
+     </para>
+
+     <para>
+      A process trying to delete SLRU segments could deadlock with the
+      checkpointer process.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [a8458f508] 2024-07-13 14:59:46 +1200
+Branch: REL_17_STABLE [3c1c82d40] 2024-07-13 15:02:33 +1200
+Branch: REL_16_STABLE [a622095bc] 2024-07-13 15:27:35 +1200
+Branch: REL_15_STABLE [5546a834c] 2024-07-13 15:28:38 +1200
+Branch: REL_14_STABLE [894b497ac] 2024-07-13 15:43:43 +1200
+Branch: REL_13_STABLE [3554d841d] 2024-07-13 15:44:11 +1200
+Branch: REL_12_STABLE [ba9fcac72] 2024-07-13 15:45:28 +1200
+-->
+     <para>
+      Avoid possibly missing end-of-input events on Windows sockets
+      (Thomas Munro)
+     </para>
+
+     <para>
+      Windows reports an FD_CLOSE event only once after the remote end of
+      the connection disconnects.  With unlucky timing, we could miss that
+      report and wait indefinitely, or at least until a timeout elapsed,
+      expecting more input.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_17_BR [855517307] 2024-05-09 12:45:37 +0900
+Branch: REL_16_STABLE [5396a2987] 2024-05-09 12:45:43 +0900
+Branch: REL_15_STABLE [8c3f30e67] 2024-05-09 12:45:45 +0900
+Branch: REL_14_STABLE [41adf9d96] 2024-05-09 12:45:48 +0900
+Branch: REL_13_STABLE [377c25d32] 2024-05-09 12:45:51 +0900
+-->
+     <para>
+      Fix buffer overread in JSON parse error reports for incomplete byte
+      sequences (Jacob Champion)
+     </para>
+
+     <para>
+      It was possible to walk off the end of the input buffer by a few
+      bytes when the last bytes comprise an incomplete multi-byte
+      character.  While usually harmless, in principle this could cause a
+      crash.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Daniel Gustafsson <dgustafsson@postgresql.org>
+Branch: master [274bbced8] 2024-07-26 11:09:45 +0200
+Branch: REL_17_STABLE [3df7f44a8] 2024-07-26 11:09:45 +0200
+Branch: REL_16_STABLE [cc606afce] 2024-07-26 11:09:45 +0200
+Branch: REL_15_STABLE [118ec331b] 2024-07-26 11:09:45 +0200
+Branch: REL_14_STABLE [ecbb1cd9b] 2024-07-26 11:09:45 +0200
+Branch: REL_13_STABLE [1f476bc75] 2024-07-26 11:09:45 +0200
+Branch: REL_12_STABLE [32121c077] 2024-07-26 11:09:45 +0200
+Branch: master [161c73462] 2024-07-26 16:25:28 +0200
+Branch: REL_17_STABLE [1272cfb72] 2024-07-26 16:25:56 +0200
+Branch: REL_16_STABLE [83b4a6358] 2024-07-26 16:29:47 +0200
+Branch: REL_15_STABLE [970cd5c62] 2024-07-26 14:16:40 +0200
+Branch: REL_14_STABLE [51c1b4fd1] 2024-07-26 14:16:40 +0200
+Branch: REL_13_STABLE [40e8ea949] 2024-07-26 14:16:40 +0200
+Branch: REL_12_STABLE [ac77add23] 2024-07-26 14:16:40 +0200
+Branch: REL_16_STABLE [441eba34d] 2024-07-26 16:29:52 +0200
+Branch: REL_15_STABLE [ce3045e9b] 2024-07-26 19:09:27 +0200
+Branch: REL_14_STABLE [ddd66a629] 2024-07-26 19:09:54 +0200
+Branch: REL_13_STABLE [634710dfb] 2024-07-26 19:10:12 +0200
+Branch: REL_12_STABLE [e6dd0b863] 2024-07-26 19:10:37 +0200
+-->
+     <para>
+      Disable creation of stateful TLS session tickets by OpenSSL
+      (Daniel Gustafsson)
+     </para>
+
+     <para>
+      This avoids possible failures with clients that think receipt of
+      a session ticket means that TLS session resumption is supported.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [6dfac2440] 2024-06-13 13:37:49 -0400
+Branch: REL_16_STABLE [82a931d3d] 2024-06-13 13:37:49 -0400
+Branch: REL_15_STABLE [bf552b1b2] 2024-06-13 13:37:50 -0400
+Branch: REL_14_STABLE [1450db793] 2024-06-13 13:37:50 -0400
+Branch: REL_13_STABLE [1fa46dba5] 2024-06-13 13:37:50 -0400
+Branch: REL_12_STABLE [ec210914c] 2024-06-13 13:37:51 -0400
+-->
+     <para>
+      When replanning a <application>PL/pgSQL</application> <quote>simple
+      expression</quote>, check it's still simple (Tom Lane)
+     </para>
+
+     <para>
+      Certain fairly-artificial cases, such as dropping a referenced
+      function and recreating it as an aggregate, could lead to surprising
+      failures such as <quote>unexpected plan node type</quote>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master Release: REL_17_BR [cd2624fd9] 2024-06-04 11:48:01 +0100
+Branch: REL_16_STABLE [b4e909082] 2024-06-04 11:51:25 +0100
+-->
+     <para>
+      Fix <application>PL/pgSQL</application>'s handling of integer ranges
+      containing underscores (Erik Wienhold)
+     </para>
+
+     <para>
+      As of v16 we allow integer literals to contain underscores,
+      but <application>PL/pgSQL</application> failed to handle examples
+      such as <literal>FOR i IN 1_001..1_003</literal>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: REL_15_STABLE [f853e23bf] 2024-06-26 07:01:47 -0400
+Branch: REL_14_STABLE [20f22e6a6] 2024-06-26 07:24:35 -0400
+Branch: REL_13_STABLE [b7374f15b] 2024-06-26 07:25:00 -0400
+Branch: REL_12_STABLE [ab46e132f] 2024-06-26 07:25:10 -0400
+Branch: REL_11_STABLE [e1541d518] 2024-06-26 07:25:26 -0400
+Branch: REL_10_STABLE [320534f8f] 2024-06-26 07:25:35 -0400
+Branch: REL9_6_STABLE [12c8faaa7] 2024-06-26 07:29:31 -0400
+Branch: REL9_5_STABLE [0536f8e2c] 2024-06-26 07:30:01 -0400
+Branch: REL9_4_STABLE [8851d5c3a] 2024-06-26 07:30:06 -0400
+Branch: REL9_3_STABLE [8f3be9661] 2024-06-26 07:30:11 -0400
+Branch: REL9_2_STABLE [1c4173116] 2024-06-26 07:32:15 -0400
+-->
+     <para>
+      Fix incompatibility between <application>PL/Perl</application> and
+      Perl 5.40 (Andrew Dunstan)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [d727c5431] 2024-05-09 13:16:34 -0400
+Branch: REL_16_STABLE [52ea653aa] 2024-05-09 13:16:21 -0400
+Branch: REL_15_STABLE [6e29963ed] 2024-05-09 13:16:21 -0400
+Branch: REL_14_STABLE [d39337021] 2024-05-09 13:16:21 -0400
+Branch: REL_13_STABLE [272867792] 2024-05-09 13:16:21 -0400
+Branch: REL_12_STABLE [157b1e6b4] 2024-05-09 13:16:21 -0400
+-->
+     <para>
+      Fix recursive <type>RECORD</type>-returning
+      <application>PL/Python</application> functions (Tom Lane)
+     </para>
+
+     <para>
+      If we recurse to a new call of the same function that passes a
+      different column definition list (<literal>AS</literal> clause), it
+      would fail because the inner call would overwrite the outer call's
+      idea of what rowtype to return.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [c5bec5426] 2024-05-07 18:15:00 -0400
+Branch: REL_16_STABLE [be18a12b6] 2024-05-07 18:15:00 -0400
+Branch: REL_15_STABLE [363e8c2f9] 2024-05-07 18:15:00 -0400
+Branch: REL_14_STABLE [90d39929a] 2024-05-07 18:15:00 -0400
+Branch: REL_13_STABLE [abe60b6a0] 2024-05-07 18:15:00 -0400
+Branch: REL_12_STABLE [4488142a4] 2024-05-07 18:15:00 -0400
+-->
+     <para>
+      Don't corrupt <application>PL/Python</application>'s
+      <literal>TD</literal> dictionary during a recursive trigger call
+      (Tom Lane)
+     </para>
+
+     <para>
+      If a <application>PL/Python</application>-language trigger caused
+      another one to be invoked, the <literal>TD</literal> dictionary
+      created for the inner one would overwrite the outer
+      one's <literal>TD</literal> dictionary.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [b631d0149] 2024-06-04 18:02:13 -0400
+Branch: REL_16_STABLE [c236ecc82] 2024-06-04 18:02:13 -0400
+Branch: REL_15_STABLE [89ef2aeda] 2024-06-04 18:02:13 -0400
+Branch: REL_14_STABLE [1488dee08] 2024-06-04 18:02:13 -0400
+Branch: REL_13_STABLE [dda633a03] 2024-06-04 18:02:13 -0400
+Branch: REL_12_STABLE [30487423c] 2024-06-04 18:02:13 -0400
+-->
+     <para>
+      Fix <application>PL/Tcl</application>'s reporting of invalid list
+      syntax in the result of a function returning tuple (Erik Wienhold,
+      Tom Lane)
+     </para>
+
+     <para>
+      Such a case could result in a crash, or in emission of misleading
+      context information that actually refers to the previous Tcl error.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+Branch: master [1e666fd7c] 2024-07-28 09:23:24 +0200
+Branch: REL_17_STABLE [821fbd63e] 2024-07-28 10:19:57 +0200
+Branch: REL_16_STABLE [c53016860] 2024-07-28 09:25:03 +0200
+Branch: REL_15_STABLE [6ddc8556c] 2024-07-28 09:25:52 +0200
+Branch: REL_14_STABLE [95e805e9c] 2024-07-28 09:26:21 +0200
+Branch: REL_13_STABLE [da5d7a771] 2024-07-28 09:26:39 +0200
+Branch: REL_12_STABLE [407048999] 2024-07-28 09:26:48 +0200
+-->
+     <para>
+      Avoid non-thread-safe usage of <function>strerror()</function>
+      in <application>libpq</application> (Peter Eisentraut)
+     </para>
+
+     <para>
+      Certain error messages returned by OpenSSL could become garbled in
+      multi-threaded applications.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Daniel Gustafsson <dgustafsson@postgresql.org>
+Branch: master Release: REL_17_BR [a8f87d5d2] 2024-05-15 22:48:51 +0200
+Branch: REL_16_STABLE [0ae05c18e] 2024-05-15 22:48:51 +0200
+Branch: REL_15_STABLE [e6fc3b70d] 2024-05-15 22:48:51 +0200
+-->
+     <para>
+      Avoid memory leak within <application>pg_dump</application> during a
+      binary upgrade (Daniel Gustafsson)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [c1aea206e] 2024-05-07 18:22:52 -0400
+Branch: REL_16_STABLE [5dce8ce0a] 2024-05-07 18:23:01 -0400
+Branch: REL_15_STABLE [6a458d93b] 2024-05-07 18:23:07 -0400
+Branch: REL_14_STABLE [52b23b4e1] 2024-05-07 18:23:11 -0400
+Branch: REL_13_STABLE [b99dc6694] 2024-05-07 18:23:15 -0400
+Branch: REL_12_STABLE [a3c00ab15] 2024-05-07 18:23:20 -0400
+-->
+     <para>
+      Ensure that <literal>pg_restore</literal> <option>-l</option>
+      reports dependent TOC entries correctly (Tom Lane)
+     </para>
+
+     <para>
+      If <option>-l</option> was specified together with selective-restore
+      options such as <option>-n</option> or <option>-N</option>,
+      dependent TOC entries such as comments would be omitted from the
+      listing, even when an actual restore would have selected them.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [c145f321b] 2024-07-19 10:21:01 +0900
+Branch: REL_17_STABLE [38e271d3c] 2024-07-19 10:21:21 +0900
+Branch: REL_16_STABLE [9cd365f28] 2024-07-19 10:21:24 +0900
+-->
+     <para>
+      Allow <filename>contrib/pg_stat_statements</filename> to distinguish
+      among utility statements appearing within SQL-language functions
+      (Anthonin Bonnefoy)
+     </para>
+
+     <para>
+      The SQL-language function executor failed to pass along the query ID
+      that is computed for a utility
+      (non <command>SELECT</command>/<command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>/<command>MERGE</command>)
+      statement.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Etsuro Fujita <efujita@postgresql.org>
+Branch: master [5c571a34d] 2024-07-19 13:15:00 +0900
+Branch: REL_17_STABLE [935fe79ea] 2024-07-19 13:15:01 +0900
+Branch: REL_16_STABLE [d97f2ee50] 2024-07-19 13:15:03 +0900
+Branch: REL_15_STABLE [f39f3e0fb] 2024-07-19 13:15:05 +0900
+-->
+     <para>
+      Avoid <quote>cursor can only scan forward</quote> error
+      in <filename>contrib/postgres_fdw</filename> (Etsuro Fujita)
+     </para>
+
+     <para>
+      This error could occur if the remote server is v15 or later
+      and a foreign table is mapped to a non-trivial remote view.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Etsuro Fujita <efujita@postgresql.org>
+Branch: master Release: REL_17_BR [8cfbac149] 2024-06-07 17:45:00 +0900
+Branch: REL_16_STABLE [8405d5a37] 2024-06-07 17:45:02 +0900
+Branch: REL_15_STABLE [b33c141cc] 2024-06-07 17:45:04 +0900
+Branch: REL_14_STABLE [269e2c391] 2024-06-07 17:45:06 +0900
+Branch: REL_13_STABLE [2b461efc5] 2024-06-07 17:45:08 +0900
+-->
+     <para>
+      In <filename>contrib/postgres_fdw</filename>, do not
+      send <literal>FETCH FIRST WITH TIES</literal> clauses to the remote
+      server (Japin Li)
+     </para>
+
+     <para>
+      The remote server might not implement this clause, or might
+      interpret it differently than we would locally, so don't risk
+      attempting remote execution.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [2a5ef0983] 2024-07-06 10:27:16 +1200
+Branch: REL_17_STABLE [9c273679b] 2024-07-06 11:23:40 +1200
+Branch: REL_16_STABLE [31423bc44] 2024-07-06 11:18:29 +1200
+Branch: REL_15_STABLE [467d77bb1] 2024-07-06 10:53:13 +1200
+Branch: REL_14_STABLE [c2342a925] 2024-07-06 10:44:41 +1200
+Branch: REL_13_STABLE [440aedc0f] 2024-07-06 10:39:10 +1200
+Branch: REL_12_STABLE [274a8195d] 2024-07-06 10:30:03 +1200
+-->
+     <para>
+      Avoid clashing with
+      system-provided <filename>&lt;regex.h&gt;</filename> headers
+      (Thomas Munro)
+     </para>
+
+     <para>
+      This fixes a compilation failure on macOS version 15 and up.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master Release: REL_17_BR [aa901a37c] 2024-06-19 10:20:24 +1200
+Branch: REL_16_STABLE [6143c9c03] 2024-06-19 10:21:00 +1200
+Branch: REL_15_STABLE [27c6242a0] 2024-06-19 10:21:26 +1200
+Branch: REL_14_STABLE [dae9f16aa] 2024-06-19 10:21:52 +1200
+-->
+     <para>
+      Fix otherwise-harmless assertion failure in Memoize cost estimation
+      (David Rowley)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_17_BR [92c49d106] 2024-06-17 14:30:59 -0400
+Branch: REL_16_STABLE [06f81fed3] 2024-06-17 14:30:59 -0400
+Branch: REL_15_STABLE [f55083319] 2024-06-17 14:30:59 -0400
+Branch: REL_14_STABLE [e4a55378f] 2024-06-17 14:30:59 -0400
+Branch: REL_13_STABLE [507a900ad] 2024-06-17 14:30:59 -0400
+Branch: REL_12_STABLE [3e3e2ebea] 2024-06-17 14:30:59 -0400
+-->
+     <para>
+      Fix otherwise-harmless assertion failures in <literal>REINDEX
+      CONCURRENTLY</literal> applied to an SP-GiST index (Tom Lane)
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-16-3">
   <title>Release 16.3</title>