summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: e52a44b)
raw | patch | inline | side by side (parent: e52a44b)
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Sun, 4 Aug 2024 17:38:59 +0000 (13:38 -0400) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Sun, 4 Aug 2024 17:38:59 +0000 (13:38 -0400) |
| doc/src/sgml/release-15.sgml | patch | blob | blame | history |
index e74161cb8082328a56aa743c2551329a12c0d39f..d5d96b3a6d0dddce6710e7109f7ad659f2ae11cd 100644 (file)
<!-- doc/src/sgml/release-15.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-15-8">
+ <title>Release 15.8</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2024-08-08</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 15.7.
+ For information about new features in major release 15, see
+ <xref linkend="release-15"/>.
+ </para>
+
+ <sect2>
+ <title>Migration to Version 15.8</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.7,
+ see <xref linkend="release-15-7"/>.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <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
+ (Á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
+ (Á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> (Á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: 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: 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: 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: 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: 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><regex.h></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-15-7">
<title>Release 15.7</title>