<!-- doc/src/sgml/release-12.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-12-20">
+ <title>Release 12.20</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2024-08-08</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 12.19.
+ For information about new features in major release 12, see
+ <xref linkend="release-12"/>.
+ </para>
+
+ <para>
+ The <productname>PostgreSQL</productname> community will stop
+ releasing updates for the 12.X release series in November 2024.
+ Users are encouraged to update to a newer release branch soon.
+ </para>
+
+ <sect2>
+ <title>Migration to Version 12.20</title>
+
+ <para>
+ A dump/restore is not required for those running 12.X.
+ </para>
+
+ <para>
+ However, if you are upgrading from a version earlier than 12.18,
+ see <xref linkend="release-12-18"/>.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <listitem>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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>
+<!--
+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-12-19">
<title>Release 12.19</title>
projects / postgresql.git / commitdiff