First-draft release notes for 15.2.

As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.

1 files changed, 1293 insertions, 0 deletions

diff --git a/doc/src/sgml/release-15.sgml b/doc/src/sgml/release-15.sgml
index 78aa7c1bb80..0c1043c92e1 100644
--- a/doc/src/sgml/release-15.sgml
+++ b/doc/src/sgml/release-15.sgml
@@ -1,6 +1,1299 @@
 <!-- doc/src/sgml/release-15.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-15-2">
+  <title>Release 15.2</title>
+
+  <formalpara>
+  <title>Release date:</title>
+  <para>2023-02-09</para>
+  </formalpara>
+
+  <para>
+   This release contains a variety of fixes from 15.1.
+   For information about new features in major release 15, see
+   <xref linkend="release-15"/>.
+  </para>
+
+  <sect2>
+   <title>Migration to Version 15.2</title>
+
+   <para>
+    A dump/restore is not required for those running 15.X.
+   </para>
+
+   <para>
+    However, if you are upgrading from a version earlier than 15.1,
+    see <xref linkend="release-15-1"/>.
+   </para>
+  </sect2>
+
+  <sect2>
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [3f7836ff6] 2023-01-05 14:12:17 -0500
+Branch: REL_15_STABLE [3706cc97a] 2023-01-05 14:12:17 -0500
+Branch: REL_14_STABLE [8cd190e13] 2023-01-05 14:12:17 -0500
+Branch: REL_13_STABLE [ad38e2f89] 2023-01-05 14:12:17 -0500
+Branch: master [3f244d020] 2023-01-15 13:14:52 -0500
+Branch: REL_15_STABLE [a8f7687a0] 2023-01-15 14:06:46 -0500
+Branch: REL_14_STABLE [a8b88c26f] 2023-01-15 14:06:46 -0500
+Branch: REL_13_STABLE [787db4be9] 2023-01-15 14:06:46 -0500
+-->
+     <para>
+      Fix calculation of which <literal>GENERATED</literal> columns need
+      to be updated in child tables during an <command>UPDATE</command> on
+      a partitioned table or inheritance tree (Amit Langote, Tom Lane)
+     </para>
+
+     <para>
+      This fixes failure to update <literal>GENERATED</literal> columns
+      that do not exist in the parent table, or that have different
+      dependencies than are in the parent column's generation expression.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [fe9e658f4] 2023-01-30 10:04:57 +0000
+Branch: REL_15_STABLE [4785af9e6] 2023-01-30 10:07:32 +0000
+-->
+     <para>
+      Fix possible failure of <command>MERGE</command> to compute
+      <literal>GENERATED</literal> columns (Dean Rasheed)
+     </para>
+
+     <para>
+      When the first row-level action of the <command>MERGE</command> was
+      an <literal>UPDATE</literal>, any
+      subsequent <literal>INSERT</literal> actions would fail to
+      compute <literal>GENERATED</literal> columns that were deemed
+      unnecessary to compute for the <literal>UPDATE</literal> action
+      (due to not depending on any of the <literal>UPDATE</literal> target
+      columns).
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [f026c16a2] 2023-01-10 14:17:47 +0000
+Branch: REL_15_STABLE [38255f2d0] 2023-01-10 14:16:27 +0000
+-->
+     <para>
+      Fix <command>MERGE</command>'s check for
+      unreachable <literal>WHEN</literal> clauses (Dean Rasheed)
+     </para>
+
+     <para>
+      A <literal>WHEN</literal> clause following an
+      unconditional <literal>WHEN</literal> clause should be rejected as
+      unreachable, but this case was not always detected.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [7b2ccc5e0] 2022-11-25 13:31:48 +0000
+Branch: REL_15_STABLE [04d61bfe6] 2022-11-25 13:29:51 +0000
+-->
+     <para>
+      Fix <command>MERGE</command>'s rule-detection test (Dean Rasheed)
+     </para>
+
+     <para>
+      <command>MERGE</command> is not supported on tables with rules;
+      but it also failed on tables that once had rules but no longer do.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master [6ff5aa129] 2022-11-17 18:56:11 +0100
+Branch: REL_15_STABLE [3d45edcef] 2022-11-17 18:56:11 +0100
+-->
+     <para>
+      In <command>MERGE</command>, don't count a <literal>DO
+      NOTHING</literal> action as a processed tuple (&Aacute;lvaro Herrera)
+     </para>
+
+     <para>
+      This makes the code's behavior match the documentation.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [935277b24] 2022-12-16 13:07:42 -0500
+Branch: REL_15_STABLE [ae98debf7] 2022-12-16 13:07:42 -0500
+Branch: REL_14_STABLE [ea5ae4cae] 2022-12-16 13:07:42 -0500
+-->
+     <para>
+      Allow a <literal>WITH RECURSIVE ... CYCLE</literal> CTE
+      to access its output column (Tom Lane)
+     </para>
+
+     <para>
+      A reference to the <literal>SET</literal> column from within the CTE
+      would fail with <quote>cache lookup failed for type 0</quote>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Etsuro Fujita <efujita@postgresql.org>
+Branch: master [ffbb7e65a] 2022-11-25 17:45:00 +0900
+Branch: REL_15_STABLE [fc02019c0] 2022-11-25 17:45:01 +0900
+Branch: REL_14_STABLE [e52245228] 2022-11-25 17:45:03 +0900
+Branch: master [4b3e37993] 2022-12-08 16:15:00 +0900
+Branch: REL_15_STABLE [a0bf7a0ec] 2022-12-08 16:15:01 +0900
+Branch: REL_14_STABLE [d43a97ef4] 2022-12-08 16:15:03 +0900
+-->
+     <para>
+      Fix handling of pending inserts when doing a bulk insertion to a
+      foreign table (Etsuro Fujita)
+     </para>
+
+     <para>
+      In some cases pending insertions were not flushed to the FDW soon
+      enough, leading to logical inconsistencies, for
+      example <literal>BEFORE ROW</literal> triggers not seeing rows they
+      should be able to see.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [c9f7f9264] 2023-01-21 13:10:29 -0500
+Branch: REL_15_STABLE [9e4288ce6] 2023-01-21 13:10:29 -0500
+Branch: REL_14_STABLE [70ec756b0] 2023-01-21 13:10:29 -0500
+Branch: REL_13_STABLE [72d611109] 2023-01-21 13:10:29 -0500
+Branch: REL_12_STABLE [a5f3f2fce] 2023-01-21 13:10:30 -0500
+Branch: REL_11_STABLE [6c122edde] 2023-01-21 13:10:30 -0500
+-->
+     <para>
+      Allow <literal>REPLICA IDENTITY</literal>
+      to be set on an index that's not (yet) valid (Tom Lane)
+     </para>
+
+     <para>
+      When <application>pg_dump</application> dumps a partitioned index
+      that's marked <literal>REPLICA IDENTITY</literal>, it generates a
+      command sequence that applies <literal>REPLICA IDENTITY</literal>
+      before the partitioned index has been marked valid, causing restore
+      to fail.  There seems no very good reason to prohibit doing it in
+      that order, so allow it.  The marking will have no effect anyway
+      until the index becomes valid.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [2605643a3] 2022-12-03 12:11:33 +0000
+Branch: REL_15_STABLE [c67204db6] 2022-12-03 12:14:36 +0000
+Branch: REL_14_STABLE [2c7ed9f75] 2022-12-03 12:16:07 +0000
+Branch: REL_13_STABLE [3bed88123] 2022-12-03 12:17:47 +0000
+Branch: REL_12_STABLE [33f600f04] 2022-12-03 12:18:58 +0000
+Branch: REL_11_STABLE [30f9b03a0] 2022-12-03 12:20:02 +0000
+-->
+     <para>
+      Fix handling of <literal>DEFAULT</literal> markers in rules that
+      perform an <command>INSERT</command> from a
+      multi-row <literal>VALUES</literal> list (Dean Rasheed)
+     </para>
+
+     <para>
+      In some cases a <literal>DEFAULT</literal> marker would not get
+      replaced with the proper default-value expression, leading to
+      an <quote>unrecognized node type</quote> error.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alexander Korotkov <akorotkov@postgresql.org>
+Branch: master [3161ae86c] 2023-01-12 18:16:34 +0300
+Branch: REL_15_STABLE [4dc3f94fa] 2023-01-12 18:17:43 +0300
+Branch: REL_14_STABLE [0d9221f1d] 2023-01-12 18:18:04 +0300
+Branch: REL_13_STABLE [2ff3ac3b5] 2023-01-12 18:18:31 +0300
+Branch: REL_12_STABLE [9e24e4781] 2023-01-12 18:19:19 +0300
+-->
+     <para>
+      Reject uses of undefined variables in <type>jsonpath</type>
+      existence checks (Alexander Korotkov, David G. Johnston)
+     </para>
+
+     <para>
+      While <type>jsonpath</type> match operators threw an error for an
+      undefined variable in the path pattern, the existence operators
+      silently treated it as a match.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [b0feda79f] 2022-12-12 16:17:54 -0500
+Branch: REL_15_STABLE [d79b76b10] 2022-12-12 16:17:49 -0500
+Branch: REL_14_STABLE [a18328bb3] 2022-12-12 16:17:49 -0500
+-->
+     <para>
+      Fix <type>jsonb</type> subscripting to cope with toasted subscript
+      values (Tom Lane, David G. Johnston)
+     </para>
+
+     <para>
+      Using a text value fetched directly from a table as
+      a <type>jsonb</type> subscript was likely to fail.
+      Fetches would usually not find any matching element.
+      Assignments could store the value with a garbage key,
+      although keys long enough to cause that problem are probably rare in
+      the field.
+     </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 shared tuplestores (Dmitry Astapov)
+     </para>
+
+     <para>
+      If the final chunk of a large tuple being written out to disk was
+      exactly 32760 bytes, it would be corrupted due to a fencepost bug.
+      This is a hazard for parallelized plans that require a tuplestore,
+      such as parallel hash join.  The query would typically fail later
+      with corrupted-data symptoms.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [7e8a80d1f] 2023-01-19 13:13:05 +0900
+Branch: REL_15_STABLE [49e3a5e71] 2023-01-19 13:13:27 +0900
+Branch: REL_14_STABLE [2e21e2857] 2023-01-19 13:13:28 +0900
+Branch: REL_13_STABLE [fed4e92f3] 2023-01-19 13:13:30 +0900
+Branch: REL_12_STABLE [162a48287] 2023-01-19 13:13:32 +0900
+Branch: REL_11_STABLE [0c2f34af7] 2023-01-19 13:13:34 +0900
+-->
+     <para>
+      Honor non-default settings
+      of <varname>checkpoint_completion_target</varname>
+      (Bharath Rupireddy)
+     </para>
+
+     <para>
+      Internal state was not updated after a change
+      in <varname>checkpoint_completion_target</varname>, possibly
+      resulting in performing checkpoint I/O faster or slower than
+      desired, especially if that setting was changed on-the-fly.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [44e9e3426] 2023-01-19 12:23:20 -0500
+Branch: REL_15_STABLE [abe203304] 2023-01-19 12:23:20 -0500
+Branch: REL_14_STABLE [103450724] 2023-01-19 12:23:20 -0500
+Branch: REL_13_STABLE [1b9a0b96a] 2023-01-19 12:23:20 -0500
+Branch: REL_12_STABLE [87591db19] 2023-01-19 12:23:20 -0500
+Branch: REL_11_STABLE [0a269527f] 2023-01-19 12:23:20 -0500
+-->
+     <para>
+      Log the correct ending timestamp
+      in <varname>recovery_target_xid</varname> mode (Tom Lane)
+     </para>
+
+     <para>
+      When ending recovery based on the <varname>recovery_target_xid</varname>
+      setting with <varname>recovery_target_inclusive</varname>
+      = <literal>off</literal>, we printed an incorrect timestamp (always
+      2000-01-01) in the <quote>recovery stopping before
+      ... transaction</quote> log message.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+Branch: master [1561612e3] 2023-01-16 09:44:04 +0100
+Branch: REL_15_STABLE [ac01fa647] 2023-01-16 09:45:03 +0100
+Branch: REL_14_STABLE [f463335e1] 2023-01-16 09:48:09 +0100
+Branch: REL_13_STABLE [cf74b6ead] 2023-01-16 09:54:15 +0100
+-->
+     <para>
+      Improve error reporting for some buffered file read failures
+      (Peter Eisentraut)
+     </para>
+
+     <para>
+      Correctly report a short read, giving the numbers of bytes desired
+      and actually read, instead of reporting an irrelevant error code.
+      Most places got this right already, but some recently-written
+      replication logic did not.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [647fa5005] 2023-01-15 17:32:09 -0500
+Branch: REL_15_STABLE [db9127c58] 2023-01-15 17:32:09 -0500
+-->
+     <para>
+      Remove arbitrary limit on number of elements
+      in <type>int2vector</type> and <type>oidvector</type> (Tom Lane)
+     </para>
+
+     <para>
+      The input functions for these types previously rejected more than
+      100 elements.  With the introduction of the logical replication
+      column list feature, it's necessary to
+      accept <type>int2vector</type>s having up to 1600 columns,
+      otherwise long column lists cause logical-replication failures.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: REL_13_STABLE [72b6098be] 2023-01-11 09:56:14 +0900
+Branch: REL_12_STABLE [c0ee6943c] 2023-01-11 09:56:18 +0900
+-->
+     <para>
+      Prevent <quote>wrong tuple length</quote> failure
+      at the end of <command>VACUUM</command> (Ashwin Agrawal, Junfeng Yang)
+     </para>
+
+     <para>
+      This occurred if <command>VACUUM</command> needed to update the
+      current database's <structfield>datfrozenxid</structfield> value and
+      the database has so many granted privileges that
+      its <structfield>datacl</structfield> value has been pushed
+      out-of-line.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [20432f873] 2022-12-13 14:23:58 -0500
+Branch: REL_15_STABLE [18431ee6f] 2022-12-13 14:23:59 -0500
+Branch: REL_14_STABLE [ae47f8a96] 2022-12-13 14:23:59 -0500
+Branch: REL_13_STABLE [942cc240f] 2022-12-13 14:23:59 -0500
+Branch: REL_12_STABLE [1cca4a75f] 2022-12-13 14:23:59 -0500
+Branch: REL_11_STABLE [f48aa5df4] 2022-12-13 14:23:59 -0500
+-->
+     <para>
+      In extended query protocol, avoid an immediate commit
+      after <command>ANALYZE</command> if we're running a pipeline
+      (Tom Lane)
+     </para>
+
+     <para>
+      If there's not been an explicit <command>BEGIN
+      TRANSACTION</command>, <command>ANALYZE</command> would take it on
+      itself to commit, which should not happen within a pipelined series
+      of commands.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [e52daaabf] 2023-01-21 06:08:00 -0800
+Branch: REL_15_STABLE [b152bb7b2] 2023-01-21 06:08:03 -0800
+Branch: REL_14_STABLE [6900aea67] 2023-01-21 06:08:04 -0800
+Branch: REL_13_STABLE [a9bccffe5] 2023-01-21 06:08:04 -0800
+Branch: REL_12_STABLE [e75b5c855] 2023-01-21 06:08:04 -0800
+Branch: REL_11_STABLE [8f70de7e0] 2023-01-21 06:08:05 -0800
+-->
+     <para>
+      Reject cancel request packets having the wrong length
+      (Andrey Borodin)
+     </para>
+
+     <para>
+      The server would process a cancel request even if its length word
+      was too small.  This led to reading beyond the end of the allocated
+      buffer.  In theory that could cause a segfault, but it seems quite
+      unlikely to happen in practice, since the buffer would have to be
+      very close to the end of memory.  The more likely outcome was a bogus
+      log message about wrong backend PID or cancel code.  Complain about
+      the wrong length, instead.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [94985c210] 2022-12-10 19:27:20 +1300
+Branch: REL_15_STABLE [04788ee4c] 2022-12-10 19:27:53 +1300
+-->
+     <para>
+      Fix planner preprocessing oversights for window function run-condition
+      expressions (Richard Guo, David Rowley)
+     </para>
+
+     <para>
+      This could lead to planner errors such as <quote>WindowFunc not
+      found in subplan target lists</quote>.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [a85832722] 2022-12-07 00:09:36 +1300
+Branch: REL_15_STABLE [2a535620c] 2022-12-07 00:10:21 +1300
+-->
+     <para>
+      Fix possible dangling-pointer access during execution of window
+      function run-condition expressions (David Rowley)
+     </para>
+
+     <para>
+      In practice, because the run-condition optimization is only applied
+      to certain window functions that happen to all
+      return <type>int8</type>, this only manifested as a problem on
+      32-bit builds.
+     </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 [d69d01ba9] 2022-12-05 12:36:40 -0500
+Branch: REL_15_STABLE [c959f84c2] 2022-12-05 12:36:41 -0500
+Branch: REL_14_STABLE [dc3648f65] 2022-12-05 12:36:41 -0500
+Branch: master [e76913802] 2022-12-04 13:48:12 -0500
+Branch: REL_15_STABLE [834d97c32] 2022-12-04 13:48:12 -0500
+Branch: REL_14_STABLE [ce093aa18] 2022-12-04 13:48:12 -0500
+-->
+     <para>
+      Fix planner issues when combining Memoize nodes with partitionwise
+      joins or parameterized nestloops (Richard Guo)
+     </para>
+
+     <para>
+      These errors could lead to not using Memoize in contexts where it
+      would be useful, or possibly to wrong query plans.
+     </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: Andres Freund <andres@anarazel.de>
+Branch: master [cb2e7ddfe] 2022-12-02 18:10:30 -0800
+Branch: REL_15_STABLE [c6a60471a] 2022-12-02 18:07:47 -0800
+-->
+     <para>
+      Prevent the statistics machinery from getting confused when a
+      relation's relkind changes (Andres Freund)
+     </para>
+
+     <para>
+      Converting a table to a view could lead to crashes or assertion
+      failures.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [1dd6700f4] 2022-12-01 11:38:14 -0500
+Branch: REL_15_STABLE [a711b36e5] 2022-12-01 11:38:15 -0500
+Branch: REL_14_STABLE [de0ff6088] 2022-12-01 11:38:15 -0500
+-->
+     <para>
+      Fix under-parenthesized display of <literal>AT TIME ZONE</literal>
+      constructs (Tom Lane)
+     </para>
+
+     <para>
+      This could result in dump/restore failures for rules or views in
+      which an argument of <literal>AT TIME ZONE</literal> is itself an
+      expression.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [8b47ccb62] 2022-11-29 11:46:33 -0500
+Branch: REL_15_STABLE [5dfc2b753] 2022-11-29 11:46:33 -0500
+Branch: REL_14_STABLE [7715a3c24] 2022-11-29 11:46:33 -0500
+-->
+     <para>
+      Prevent clobbering of cached parsetrees for utility statements in
+      SQL functions (Tom Lane, Daniel Gustafsson)
+     </para>
+
+     <para>
+      Bad things could happen if a SQL-language function executes the same
+      utility command more than once during a calling query.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [5644d6f90] 2022-11-21 17:07:29 -0500
+Branch: REL_15_STABLE [0353db996] 2022-11-21 17:07:07 -0500
+Branch: REL_14_STABLE [1b9c04b13] 2022-11-21 17:07:07 -0500
+Branch: REL_13_STABLE [74670688f] 2022-11-21 17:07:07 -0500
+Branch: REL_12_STABLE [1aed4c4fd] 2022-11-21 17:07:07 -0500
+Branch: REL_11_STABLE [c0eed8891] 2022-11-21 17:07:07 -0500
+-->
+     <para>
+      Ensure that execution of full-text-search queries can be cancelled
+      while they are performing phrase matches (Tom Lane)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [edf12e7bb] 2022-12-01 11:49:15 -0800
+Branch: REL_15_STABLE [9377b4f30] 2022-12-01 11:55:59 -0800
+Branch: REL_14_STABLE [47e1224d5] 2022-12-01 11:53:53 -0800
+Branch: REL_13_STABLE [a844052b5] 2022-12-01 11:52:06 -0800
+Branch: REL_12_STABLE [f98c4fb1d] 2022-12-01 11:49:43 -0800
+-->
+     <para>
+      Fix memory leak in hashing strings with nondeterministic collations
+      (Jeff Davis)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [6c6d6ba3e] 2023-01-24 09:25:36 +0530
+Branch: REL_15_STABLE [267135d01] 2023-01-24 09:12:04 +0530
+Branch: REL_14_STABLE [fd270b728] 2023-01-24 09:02:05 +0530
+-->
+     <para>
+      Fix deadlock between <command>DROP DATABASE</command> and logical
+      replication worker process (Hou Zhijie)
+     </para>
+
+     <para>
+      This was caused by an ill-advised choice to block interrupts while
+      creating a logical replication slot in the worker.  In version 15
+      that could lead to an undetected deadlock.  In version 14, no
+      deadlock has been observed, but it's still a bad idea to block
+      interrupts while waiting for network I/O.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andres Freund <andres@anarazel.de>
+Branch: master [bc54ef4ec] 2023-01-23 18:27:42 -0800
+Branch: REL_15_STABLE [704a330a9] 2023-01-23 18:27:45 -0800
+Branch: REL_14_STABLE [0a796b8b3] 2023-01-23 18:27:48 -0800
+Branch: REL_13_STABLE [c5864805b] 2023-01-23 18:27:51 -0800
+Branch: REL_12_STABLE [92fc12787] 2023-01-23 18:27:55 -0800
+Branch: REL_11_STABLE [243373159] 2023-01-23 18:27:58 -0800
+-->
+     <para>
+      Clean up the <application>libpq</application> connection object
+      after a failed replication connection attempt (Andres Freund)
+     </para>
+
+     <para>
+      The previous coding leaked the connection object.  In background
+      code paths that's pretty harmless because the calling process will
+      give up and exit.  But in commands such as <command>CREATE
+      SUBSCRIPTION</command>, such a failure resulted in a small
+      session-lifespan memory leak.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [8242752f9] 2022-11-29 15:43:17 -0500
+Branch: REL_15_STABLE [55fa993d7] 2022-11-29 15:43:17 -0500
+Branch: REL_14_STABLE [06998eab1] 2022-11-29 15:43:17 -0500
+Branch: REL_13_STABLE [6e8ad1152] 2022-11-29 15:43:17 -0500
+Branch: REL_12_STABLE [c4a153d77] 2022-11-29 15:43:17 -0500
+Branch: REL_11_STABLE [a6c9e1db2] 2022-11-29 15:43:17 -0500
+-->
+     <para>
+      In hot-standby servers, reduce processing effort for tracking XIDs
+      known to be active on the primary (Simon Riggs, Michail Nikolaev)
+     </para>
+
+     <para>
+      Insufficiently-aggressive cleanup of the KnownAssignedXids array
+      could lead to poor performance, particularly
+      when <varname>max_connections</varname> is set to a large value on
+      the standby.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master [0557e1770] 2022-11-22 10:56:07 +0100
+Branch: REL_15_STABLE [1ad033df1] 2022-11-22 10:56:07 +0100
+Branch: REL_14_STABLE [1b3ed7571] 2022-11-22 10:56:07 +0100
+Branch: REL_13_STABLE [36eeb37cd] 2022-11-22 10:56:07 +0100
+-->
+     <para>
+      Ignore invalidated logical-replication slots while determining
+      oldest catalog xmin (Sirisha Chamarthi)
+     </para>
+
+     <para>
+      A replication slot could prevent cleanup of dead tuples in the
+      system catalogs even after it becomes invalidated due to
+      exceeding <varname>max_slot_wal_keep_size</varname>.  Thus, failure
+      of a replication consumer could lead to indefinitely-large catalog
+      bloat.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [2b6df0546] 2023-01-07 12:17:14 +0530
+Branch: REL_15_STABLE [18b81258a] 2023-01-07 12:04:33 +0530
+Branch: REL_14_STABLE [b2cc5b810] 2023-01-07 11:52:41 +0530
+-->
+     <para>
+      In logical decoding, notify the remote node when a transaction is
+      detected to have crashed (Hou Zhijie)
+     </para>
+
+     <para>
+      After a server restart, we'll re-stream the changes for transactions
+      occurring shortly before the restart.  Some of these transactions
+      probably never completed; when we realize that one didn't we throw
+      away the relevant decoding state locally, but we neglected to tell
+      the subscriber about it.  That led to the subscriber keeping useless
+      streaming files until it's next restarted.
+     </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: Michael Paquier <michael@paquier.xyz>
+Branch: master [5ad165d2c] 2023-01-12 13:40:33 +0900
+Branch: REL_15_STABLE [6f25e4877] 2023-01-12 13:41:22 +0900
+-->
+     <para>
+      Acquire spinlock while updating shared state during logical decoding
+      context creation (Masahiko Sawada)
+     </para>
+
+     <para>
+      We neglected to acquire the appropriate lock while updating data
+      about two-phase transactions, potentially allowing other processes
+      to see inconsistent data.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [40b149135] 2022-12-02 10:52:58 +0530
+Branch: REL_15_STABLE [ebf87c019] 2022-12-02 11:14:42 +0530
+-->
+     <para>
+      Fix <application>pgoutput</application> replication plug-in to not
+      send columns not listed in a table's replication column list
+      (Hou Zhijie)
+     </para>
+
+     <para>
+      <literal>UPDATE</literal> and <literal>DELETE</literal> events did
+      not pay attention to the configured column list, thus sending more
+      data than expected.  This did not cause a problem when the receiver
+      is our built-in logical replication code, but it might confuse other
+      receivers, and in any case it wasted network bandwidth.
+     </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: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [b2d479289] 2023-02-03 11:13:34 +0000
+Branch: REL_15_STABLE [4f74741a5] 2023-02-03 11:11:59 +0000
+Branch: REL_14_STABLE [86bfbeab4] 2023-02-03 11:09:15 +0000
+-->
+     <para>
+      Fix <function>int64_div_fast_to_numeric()</function> to work for a
+      wider range of inputs (Dean Rasheed)
+     </para>
+
+     <para>
+      This function misbehaved with some values of its second argument.
+      No such usages exist in core <productname>PostgreSQL</productname>,
+      but it's clearly a hazard for external modules, so repair.
+     </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: Tomas Vondra <tomas.vondra@postgresql.org>
+Branch: master [02699bc1f] 2022-12-30 20:49:50 +0100
+Branch: REL_15_STABLE [c4f64cfab] 2022-12-30 20:49:11 +0100
+Branch: REL_14_STABLE [883dc0214] 2022-12-30 20:47:58 +0100
+-->
+     <para>
+      Fix assertion failure in BRIN minmax-multi opclasses (Tomas Vondra)
+     </para>
+
+     <para>
+      The assertion was overly strict, so this mistake was harmless in
+      non-assert builds.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [51dfaa0b0] 2022-11-29 10:52:44 -0500
+Branch: REL_15_STABLE [556c0b913] 2022-11-29 10:52:44 -0500
+Branch: REL_14_STABLE [0224646be] 2022-11-29 10:52:44 -0500
+Branch: REL_13_STABLE [aca695fb6] 2022-11-29 10:52:44 -0500
+Branch: REL_12_STABLE [bb8d48cb9] 2022-11-29 10:52:44 -0500
+-->
+     <para>
+      Remove faulty assertion in useless-RESULT-RTE optimization logic
+      (Tom Lane)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [2fcf685f6] 2022-12-23 10:04:18 +0900
+Branch: REL_15_STABLE [e3897a3a4] 2022-12-23 10:04:30 +0900
+Branch: REL_14_STABLE [7ad458e06] 2022-12-23 10:04:33 +0900
+Branch: REL_13_STABLE [4dbe72d61] 2022-12-23 10:04:34 +0900
+Branch: REL_12_STABLE [7445869e1] 2022-12-23 10:04:36 +0900
+Branch: REL_11_STABLE [df6fea51f] 2022-12-23 10:04:37 +0900
+-->
+     <para>
+      Fix copy-and-paste errors in cache-lookup-failure messages for ACL
+      checks (Justin Pryzby)
+     </para>
+
+     <para>
+      In principle these errors should never be reached.  But if they are,
+      some of them reported the wrong type of object.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Robert Haas <rhaas@postgresql.org>
+Branch: master [45f5c81ad] 2022-12-12 10:26:48 -0500
+Branch: REL_15_STABLE [8b5ba2f3f] 2022-12-12 10:33:02 -0500
+-->
+     <para>
+      Fix possible corruption of very large tablespace map files
+      in <application>pg_basebackup</application> (Antonin Houska)
+     </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: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [74739d1d3] 2023-01-19 19:32:50 -0500
+Branch: REL_15_STABLE [488e89bf7] 2023-01-19 19:32:47 -0500
+-->
+     <para>
+      Avoid harmless warning from <application>pg_dump</application>
+      in <option>--if-exists</option> mode (Tom Lane)
+     </para>
+
+     <para>
+      If the <literal>public</literal> schema has a non-default owner then
+      use of <application>pg_dump</application>'s <option>--if-exists</option>
+      option resulted in a warning message <quote>warning: could not find
+      where to insert IF EXISTS in statement "-- *not* dropping schema,
+      since initdb creates it"</quote>.  The dump output was okay, though.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [cabfb8241] 2022-12-02 14:24:44 -0500
+Branch: REL_15_STABLE [97299cf99] 2022-12-02 14:24:44 -0500
+Branch: REL_14_STABLE [303b26c1b] 2022-12-02 14:24:44 -0500
+-->
+     <para>
+      Fix <application>psql</application>'s <literal>\sf</literal>
+      and <literal>\ef</literal> commands to handle SQL-language functions
+      that have <acronym>SQL</acronym>-standard function bodies (Tom Lane)
+     </para>
+
+     <para>
+      These commands misidentified the start of the function body when it
+      used new-style syntax.
+     </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 [aeaaf520f] 2022-11-21 15:37:10 -0500
+Branch: REL_15_STABLE [b8988cf1d] 2022-11-21 15:37:10 -0500
+-->
+     <para>
+      Update <filename>contrib/pageinspect</filename> to mark its
+      disk-accessing functions as <literal>PARALLEL RESTRICTED</literal>
+      (Tom Lane)
+     </para>
+
+     <para>
+      This avoids possible failure if one of these functions is used to
+      examine a temporary table, since a session's temporary tables are not
+      accessible from parallel workers.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Etsuro Fujita <efujita@postgresql.org>
+Branch: REL_12_STABLE [69f75bf82] 2022-12-15 21:15:00 +0900
+-->
+     <para>
+      Fix faulty assertion in <filename>contrib/postgres_fdw</filename>
+      (Etsuro Fujita)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [701c881f7] 2022-12-21 17:51:50 -0500
+Branch: REL_15_STABLE [b87037b37] 2022-12-21 17:51:50 -0500
+Branch: REL_14_STABLE [f489b480f] 2022-12-21 17:51:50 -0500
+Branch: REL_13_STABLE [d35f1d485] 2022-12-21 17:51:50 -0500
+Branch: REL_12_STABLE [c8314d62a] 2022-12-21 17:51:50 -0500
+Branch: REL_11_STABLE [0ff4056b8] 2022-12-21 17:51:50 -0500
+-->
+     <para>
+      Fix <filename>contrib/seg</filename> to not crash or print garbage
+      if an input number has more than 127 digits (Tom Lane)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: REL_13_STABLE [c304c069d] 2022-11-09 09:39:53 +0900
+Branch: REL_12_STABLE [edb4ef48d] 2022-11-09 09:39:55 +0900
+Branch: REL_11_STABLE [91723759e] 2022-11-09 09:39:57 +0900
+Branch: REL_10_STABLE [8f5d4ee6c] 2022-11-09 09:39:58 +0900
+Branch: REL9_6_STABLE [b2b988110] 2022-11-09 09:40:01 +0900
+Branch: REL9_5_STABLE [40064e103] 2022-11-09 09:40:02 +0900
+Branch: REL9_4_STABLE [0f5812df6] 2022-11-09 09:40:05 +0900
+Branch: REL9_3_STABLE [a5171b880] 2022-11-09 09:40:06 +0900
+Branch: REL9_2_STABLE [c58c0770a] 2022-11-09 09:40:09 +0900
+-->
+     <para>
+      In <filename>contrib/sepgsql</filename>, avoid deprecation warnings
+      with recent <application>libselinux</application> (Michael Paquier)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: REL_15_STABLE [576506303] 2022-11-10 10:23:49 -0500
+Branch: REL_14_STABLE [06dca17ad] 2022-11-10 10:23:49 -0500
+Branch: REL_13_STABLE [0942acb73] 2022-11-10 10:23:49 -0500
+Branch: REL_12_STABLE [cf0f465c0] 2022-11-10 10:23:49 -0500
+-->
+     <para>
+      Fix build on Microsoft Visual Studio 2013 (Tom Lane)
+     </para>
+
+     <para>
+      A previous patch supposed that all platforms of interest
+      have <function>snprintf()</function>, but MSVC 2013 isn't quite
+      there yet.  Revert to using <function>sprintf()</function> on that
+      platform.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [341f4e002] 2022-11-25 15:28:38 -0500
+Branch: REL_15_STABLE [fed54fc9a] 2022-11-25 15:37:33 -0500
+Branch: REL_14_STABLE [f76191fd9] 2022-11-25 15:37:33 -0500
+Branch: REL_13_STABLE [9fe5cff14] 2022-11-25 15:37:33 -0500
+Branch: REL_12_STABLE [171c7fffa] 2022-11-25 15:37:34 -0500
+Branch: REL_11_STABLE [ae7c51213] 2022-11-25 15:37:34 -0500
+-->
+     <para>
+      Fix compile failure in building PL/Perl with MSVC when using
+      Strawberry Perl (Andrew Dunstan)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [ccc59a83c] 2022-11-27 09:03:22 -0500
+Branch: REL_15_STABLE [b5d8fd418] 2022-11-27 09:18:14 -0500
+Branch: REL_14_STABLE [f3f70b8de] 2022-11-27 09:18:20 -0500
+Branch: REL_13_STABLE [68d89d80c] 2022-11-27 09:18:32 -0500
+Branch: REL_12_STABLE [85565cbca] 2022-11-27 09:18:40 -0500
+Branch: REL_11_STABLE [724dd5649] 2022-11-27 09:18:46 -0500
+-->
+     <para>
+      Fix mismatch of PL/Perl built with MSVC versus a Perl library built
+      with gcc (Andrew Dunstan)
+     </para>
+
+     <para>
+      Such combinations could previously fail with <quote>loadable library
+      and perl binaries are mismatched</quote> errors.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Andres Freund <andres@anarazel.de>
+Branch: master [388e80132] 2022-12-29 12:47:29 -0800
+Branch: REL_15_STABLE [c6e75e4c2] 2023-01-02 15:49:33 -0800
+Branch: REL_14_STABLE [7b5dec760] 2023-01-02 15:50:00 -0800
+Branch: REL_13_STABLE [ce073d014] 2023-01-02 15:50:33 -0800
+Branch: REL_12_STABLE [f0e13802f] 2023-01-02 15:51:03 -0800
+Branch: REL_11_STABLE [99f8bc335] 2023-01-02 15:51:05 -0800
+-->
+     <para>
+      Suppress compiler warnings from Perl's header files (Andres Freund)
+     </para>
+
+     <para>
+      Our preferred compiler options provoke warnings about constructs
+      appearing in recent versions of Perl's header files.  When using
+      <application>gcc</application>, we can suppress these warnings with
+      a pragma.
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: REL_15_STABLE [9a40a0311] 2023-01-20 11:58:12 -0500
+Branch: REL_14_STABLE [21c058648] 2023-01-20 11:58:12 -0500
+Branch: REL_13_STABLE [c78f109b8] 2023-01-20 11:58:12 -0500
+Branch: REL_12_STABLE [6d066d56b] 2023-01-20 11:58:12 -0500
+Branch: REL_11_STABLE [b69e9dfab] 2023-01-20 11:58:12 -0500
+-->
+     <para>
+      Fix <application>pg_waldump</application> to build on compilers that
+      don't discard unused static-inline functions (Tom Lane)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [758f44bc3] 2023-01-31 17:36:55 -0500
+Branch: REL_15_STABLE [65f0d9d27] 2023-01-31 17:37:06 -0500
+Branch: REL_14_STABLE [7e6154779] 2023-01-31 17:37:14 -0500
+Branch: REL_13_STABLE [20d9da107] 2023-01-31 17:37:22 -0500
+Branch: REL_12_STABLE [2c95d8776] 2023-01-31 17:37:28 -0500
+Branch: REL_11_STABLE [7ddc428ef] 2023-01-31 17:37:34 -0500
+-->
+     <para>
+      Update time zone data files to <application>tzdata</application>
+      release 2022g for DST law changes in Greenland and Mexico,
+      plus historical corrections for northern Canada, Colombia, and
+      Singapore.
+     </para>
+
+     <para>
+      Notably, a new timezone America/Ciudad_Juarez has been split off
+      from America/Ojinaga.
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-15-1">
   <title>Release 15.1</title>