Release notes for 15.2, 14.7, 13.10, 12.14, 11.19.

1 files changed, 674 insertions, 0 deletions

diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 2d4b8b599a1..87e9469953f 100644
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -1,6 +1,680 @@
 <!-- doc/src/sgml/release-11.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-11-19">
+  <title>Release 11.19</title>
+
+  <formalpara>
+  <title>Release date:</title>
+  <para>2023-02-09</para>
+  </formalpara>
+
+  <para>
+   This release contains a variety of fixes from 11.18.
+   For information about new features in major release 11, see
+   <xref linkend="release-11"/>.
+  </para>
+
+  <para>
+   The <productname>PostgreSQL</productname> community will stop
+   releasing updates for the 11.X release series in November 2023.
+   Users are encouraged to update to a newer release branch soon.
+  </para>
+
+  <sect2>
+   <title>Migration to Version 11.19</title>
+
+   <para>
+    A dump/restore is not required for those running 11.X.
+   </para>
+
+   <para>
+    However, if you are upgrading from a version earlier than 11.14,
+    see <xref linkend="release-11-14"/>.
+   </para>
+  </sect2>
+
+  <sect2>
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <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: 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: 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: 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: 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: 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: 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-11-18">
   <title>Release 11.18</title>