postgres.git / summary / log / commit / refs
commit 334582e9d72d4fcefadc8f045da175d6d0e33cf9
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun Aug 09 16:52:47 2026 +0000
Release notes for 18.5, 17.11, 16.15, 15.19, 14.24.
doc/src/sgml/release-15.sgml | 1549 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 1549 insertions(+)
diff --git a/doc/src/sgml/release-15.sgml b/doc/src/sgml/release-15.sgml
index 4975d446337..6f99e04a1f7 100644
--- a/doc/src/sgml/release-15.sgml
+++ b/doc/src/sgml/release-15.sgml
@@ -1,6 +1,1555 @@
<!-- doc/src/sgml/release-15.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-15-19">
+ <title>Release 15.19</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2026-08-13</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 15.18.
+ For information about new features in major release 15, see
+ <xref linkend="release-15"/>.
+ </para>
+
+ <sect2>
+ <title>Migration to Version 15.19</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.14,
+ see <xref linkend="release-15-14"/>.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: REL_16_STABLE [42a3194e5] 2026-05-27 11:49:50 +0300
+Branch: REL_15_STABLE [2dfe75f98] 2026-05-27 11:50:31 +0300
+Branch: REL_14_STABLE [2bb60eb4f] 2026-05-27 11:50:56 +0300
+-->
+ <para>
+ Fix self-deadlock when replaying WAL generated by an older minor
+ version (Andrey Borodin)
+ <ulink url="&commit_baseurl;2dfe75f98">§</ulink>
+ </para>
+
+ <para>
+ This error was introduced in the previous set of minor releases. It
+ caused standby servers that were following a primary of an older
+ minor release version to get stuck in some scenarios.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Etsuro Fujita <efujita@postgresql.org>
+Branch: master [f57df2068] 2026-08-07 17:30:00 +0900
+Branch: REL_19_STABLE [7d74b2644] 2026-08-07 17:30:01 +0900
+Branch: REL_18_STABLE [4ea497a92] 2026-08-07 17:30:02 +0900
+Branch: REL_17_STABLE [3704870b2] 2026-08-07 17:30:03 +0900
+Branch: REL_16_STABLE [894da35b3] 2026-08-07 17:30:04 +0900
+Branch: REL_15_STABLE [7213cbfa0] 2026-08-07 17:30:05 +0900
+Branch: REL_14_STABLE [cec48686a] 2026-08-07 17:30:06 +0900
+-->
+ <para>
+ Fix mis-handling of asynchronous reads when rescanning an
+ asynchronous Append plan node (Alexander Korotkov, Gleb Kashkin,
+ Etsuro Fujita)
+ <ulink url="&commit_baseurl;7213cbfa0">§</ulink>
+ </para>
+
+ <para>
+ When an upper plan node rescans an Append before having read the
+ entire Append output, we need to discard any in-flight requests sent
+ to external servers (by <filename>postgres_fdw</filename> for
+ example). This was not done correctly in cases where a subplan has
+ parameter changes or is discarded by partition pruning in the next
+ scan. The outcome could be incorrect query results, an infinite
+ loop, or an assertion failure.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [709dfd27f] 2026-07-31 15:36:31 +1200
+Branch: REL_19_STABLE [f9282a650] 2026-07-31 15:37:12 +1200
+Branch: REL_18_STABLE [02e69be47] 2026-07-31 15:37:42 +1200
+Branch: REL_17_STABLE [31f2acde5] 2026-07-31 15:38:10 +1200
+Branch: REL_16_STABLE [9a0cd8e73] 2026-07-31 15:38:34 +1200
+Branch: REL_15_STABLE [5190732c9] 2026-07-31 15:39:01 +1200
+Branch: REL_14_STABLE [6098f35f4] 2026-07-31 15:39:21 +1200
+-->
+ <para>
+ Fix error in partition pruning for RANGE-partitioned tables
+ (David Rowley)
+ <ulink url="&commit_baseurl;5190732c9">§</ulink>
+ </para>
+
+ <para>
+ In some cases the DEFAULT partition would be skipped when it should
+ not be, which could lead to rows missing from query results.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [239eabda4] 2026-07-28 16:09:03 -0400
+Branch: REL_19_STABLE [9740c68ff] 2026-07-28 16:09:03 -0400
+Branch: REL_18_STABLE [277122036] 2026-07-28 16:09:03 -0400
+Branch: REL_17_STABLE [26d6b7dc9] 2026-07-28 16:09:04 -0400
+Branch: REL_16_STABLE [6fcee189b] 2026-07-28 16:09:04 -0400
+Branch: REL_15_STABLE [53470ffba] 2026-07-28 16:09:04 -0400
+Branch: REL_14_STABLE [13b627a3e] 2026-07-28 16:09:04 -0400
+-->
+ <para>
+ Fix planner's nullability and strictness checks
+ for <literal><replaceable>value</replaceable> IN
+ (<replaceable>array</replaceable>)</literal> expressions
+ (Ayush Tiwari)
+ <ulink url="&commit_baseurl;53470ffba">§</ulink>
+ </para>
+
+ <para>
+ These checks should only succeed if the array operand is known to be
+ non-empty, but that consideration was missed, allowing optimizations
+ to be applied that should not be. This could result in wrong query
+ answers if the array actually was empty.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_19_BR [06e94eccf] 2026-06-08 11:48:16 -0400
+Branch: REL_18_STABLE [11aed8d19] 2026-06-08 11:48:17 -0400
+Branch: REL_17_STABLE [19152e3c2] 2026-06-08 11:48:17 -0400
+Branch: REL_16_STABLE [cf2bfe073] 2026-06-08 11:48:17 -0400
+Branch: REL_15_STABLE [caebac5f1] 2026-06-08 11:48:18 -0400
+Branch: REL_14_STABLE [64778fac7] 2026-06-08 11:48:18 -0400
+-->
+ <para>
+ Add missed checks for hashability of equality comparisons on
+ container datatypes (arrays, composites, ranges) (Andrei Lepikhov,
+ Tom Lane)
+ <ulink url="&commit_baseurl;caebac5f1">§</ulink>
+ </para>
+
+ <para>
+ The planner must verify hashability of the container's component
+ type(s) before deciding it can use a hash-based plan type. This
+ step was missed in some places, leading to <quote>could not identify
+ a hash function</quote> failures at execution.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [d007800f0] 2026-07-07 23:57:45 +1200
+Branch: REL_19_STABLE [fcd58c6d9] 2026-07-07 23:58:29 +1200
+Branch: REL_18_STABLE [cf184ec77] 2026-07-07 23:59:08 +1200
+Branch: REL_17_STABLE [be63b285e] 2026-07-07 23:59:33 +1200
+Branch: REL_16_STABLE [a85732162] 2026-07-08 00:00:03 +1200
+Branch: REL_15_STABLE [842e34efa] 2026-07-08 00:00:34 +1200
+-->
+ <para>
+ Fix mis-optimization of <function>COUNT</function> window functions
+ that have an <literal>EXCLUDE</literal> clause or
+ lack <literal>ORDER BY</literal> (Chengpeng Yan, David Rowley)
+ <ulink url="&commit_baseurl;842e34efa">§</ulink>
+ </para>
+
+ <para>
+ These window functions were treated as monotonic when they should
+ not be, allowing wrong answers to be computed.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+Branch: master [fef160d8b] 2026-08-04 09:06:46 +0200
+Branch: REL_19_STABLE [ce6e434ce] 2026-08-04 09:06:46 +0200
+Branch: REL_18_STABLE [c374f2807] 2026-08-04 09:06:46 +0200
+Branch: REL_17_STABLE [18006c1bd] 2026-08-04 09:06:46 +0200
+Branch: REL_16_STABLE [34785a0d5] 2026-08-04 09:06:46 +0200
+Branch: REL_15_STABLE [785289de0] 2026-08-04 09:06:46 +0200
+Branch: REL_14_STABLE [cad17745e] 2026-08-04 09:06:46 +0200
+-->
+ <para>
+ Fix <command>ALTER COLUMN ... DROP EXPRESSION</command> to work when
+ there are multiple levels of partitions (Alberto Piai)
+ <ulink url="&commit_baseurl;785289de0">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [a8c2547ea] 2026-07-04 11:34:26 -0400
+Branch: REL_19_STABLE [80c7f5467] 2026-07-04 11:34:26 -0400
+Branch: REL_18_STABLE [a7f7958ab] 2026-07-04 11:34:26 -0400
+Branch: REL_17_STABLE [e99fb3262] 2026-07-04 11:34:26 -0400
+Branch: REL_16_STABLE [a69503fb1] 2026-07-04 11:34:26 -0400
+Branch: REL_15_STABLE [eada45dd8] 2026-07-04 11:34:26 -0400
+Branch: REL_14_STABLE [1b17a6e3c] 2026-07-04 11:34:26 -0400
+-->
+ <para>
+ Disallow renaming a rule to <literal>_RETURN</literal> (Tom Lane)
+ <ulink url="&commit_baseurl;eada45dd8">§</ulink>
+ </para>
+
+ <para>
+ That name is reserved for a view's <literal>ON SELECT</literal>
+ rule, but <command>ALTER RULE</command> allowed renaming other rules
+ to <literal>_RETURN</literal>, causing trouble later.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [74276e685] 2026-07-28 08:33:23 +0900
+Branch: REL_19_STABLE [9f6fb1191] 2026-07-28 08:35:09 +0900
+Branch: REL_18_STABLE [e4527519b] 2026-07-28 08:35:12 +0900
+Branch: REL_17_STABLE [28269fed6] 2026-07-28 08:35:14 +0900
+Branch: REL_16_STABLE [ac222bea5] 2026-07-28 08:35:17 +0900
+Branch: REL_15_STABLE [5b3712e31] 2026-07-28 08:35:19 +0900
+Branch: REL_14_STABLE [55adef7ab] 2026-07-28 08:35:21 +0900
+-->
+ <para>
+ Fix use of <command>REINDEX CONCURRENTLY</command> with
+ a deferred uniqueness constraint (Nitin Motiani)
+ <ulink url="&commit_baseurl;5b3712e31">§</ulink>
+ </para>
+
+ <para>
+ The transient index copy created during <command>REINDEX
+ CONCURRENTLY</command> was incorrectly marked as enforcing immediate
+ uniqueness, causing spurious reports of constraint violation.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+Branch: master [fd2b89854] 2026-08-05 11:40:39 +0200
+Branch: REL_19_STABLE [55ea76426] 2026-08-05 11:40:39 +0200
+Branch: REL_18_STABLE [011384ba4] 2026-08-05 11:40:39 +0200
+Branch: REL_17_STABLE [8acfaa12a] 2026-08-05 11:40:39 +0200
+Branch: REL_16_STABLE [b594efe52] 2026-08-05 11:40:39 +0200
+Branch: REL_15_STABLE [0de744cd5] 2026-08-05 11:40:39 +0200
+Branch: REL_14_STABLE [49a712f32] 2026-08-05 11:40:39 +0200
+-->
+ <para>
+ Fix matching of localized month/day names
+ in <function>to_date()</function> (Heikki Linnakangas)
+ <ulink url="&commit_baseurl;0de744cd5">§</ulink>
+ </para>
+
+ <para>
+ The matching logic misbehaved in cases where case-folding changes
+ the byte length of the string.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [f2ff15e4c] 2026-06-05 07:50:08 +0900
+Branch: REL_18_STABLE [273fe9485] 2026-06-05 07:50:12 +0900
+Branch: REL_17_STABLE [0c9cbbfb5] 2026-06-05 07:50:13 +0900
+Branch: REL_16_STABLE [82116023e] 2026-06-05 07:50:15 +0900
+Branch: REL_15_STABLE [c391375ba] 2026-06-05 07:50:16 +0900
+Branch: REL_14_STABLE [8bb935d61] 2026-06-05 07:50:18 +0900
+-->
+ <para>
+ Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE)
+ (Diego Frias, Michael Paquier)
+ <ulink url="&commit_baseurl;c391375ba">§</ulink>
+ </para>
+
+ <para>
+ This character was treated as a valid T syllable, which it is not,
+ and hence silently swallowed during normalization.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master Release: REL_19_BR [9234e3337] 2026-06-08 11:47:53 -0700
+Branch: REL_18_STABLE [89e648498] 2026-06-08 11:47:40 -0700
+Branch: REL_17_STABLE [3805641cb] 2026-06-08 11:48:27 -0700
+Branch: REL_16_STABLE [b32df590c] 2026-06-08 11:48:48 -0700
+Branch: REL_15_STABLE [a7e0e42a2] 2026-06-08 11:49:11 -0700
+Branch: REL_14_STABLE [1e0458172] 2026-06-08 11:49:27 -0700
+-->
+ <para>
+ Avoid possible truncation of output lexemes in case-insensitive
+ <literal>synonym</literal> dictionaries (Jeff Davis)
+ <ulink url="&commit_baseurl;a7e0e42a2">§</ulink>
+ </para>
+
+ <para>
+ If folding to lower case increased the byte length of a lexeme, it
+ was incorrectly truncated to its original byte length when emitted.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [273a3c776] 2026-06-03 12:47:22 +0900
+Branch: REL_18_STABLE [b3f13c032] 2026-06-03 12:47:26 +0900
+Branch: REL_17_STABLE [203e238bb] 2026-06-03 12:47:28 +0900
+Branch: REL_16_STABLE [8b5580a05] 2026-06-03 12:47:30 +0900
+Branch: REL_15_STABLE [259b627d5] 2026-06-03 12:47:32 +0900
+Branch: REL_14_STABLE [74d3482f4] 2026-06-03 12:47:34 +0900
+-->
+ <para>
+ Fix typo in <function>hash_record_extended()</function> (Man Zeng)
+ <ulink url="&commit_baseurl;259b627d5">§</ulink>
+ </para>
+
+ <para>
+ The code failed to initialize the second isnull argument passed to
+ FunctionCallInvoke(). This is harmless for existing in-core
+ extended hash support functions, which will not examine that value.
+ However, extension-provided hash functions could be affected if they
+ inspect <literal>PG_ARGISNULL(1)</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Robert Haas <rhaas@postgresql.org>
+Branch: master [e8914ec22] 2026-07-06 12:51:29 -0400
+Branch: REL_19_STABLE [2ddc45662] 2026-07-06 12:31:42 -0400
+Branch: REL_18_STABLE [0c06ebf12] 2026-07-06 12:24:03 -0400
+Branch: REL_17_STABLE [52af6fef4] 2026-07-06 12:24:10 -0400
+Branch: REL_16_STABLE [6de480156] 2026-07-06 12:24:16 -0400
+Branch: REL_15_STABLE [d39b9eed0] 2026-07-06 12:24:23 -0400
+Branch: REL_14_STABLE [0115650de] 2026-07-06 12:24:28 -0400
+-->
+ <para>
+ Prevent <function>satisfies_hash_partition()</function> from
+ crashing with <literal>VARIADIC NULL</literal> (Robert Haas)
+ <ulink url="&commit_baseurl;d39b9eed0">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_19_BR [ce6bf3cd1] 2026-06-04 12:24:51 -0400
+Branch: REL_18_STABLE [c5194139c] 2026-06-04 12:24:51 -0400
+Branch: REL_17_STABLE [0626fbfeb] 2026-06-04 12:24:51 -0400
+Branch: REL_16_STABLE [ed5ca5828] 2026-06-04 12:24:51 -0400
+Branch: REL_15_STABLE [b3a86eb6d] 2026-06-04 12:24:51 -0400
+Branch: REL_14_STABLE [262cc4df2] 2026-06-04 12:24:51 -0400
+-->
+ <para>
+ Report invalid-weight errors more cleanly and consistently
+ in <function>tsvector_filter()</function> and allied functions
+ (Ewan Young)
+ <ulink url="&commit_baseurl;b3a86eb6d">§</ulink>
+ </para>
+
+ <para>
+ In particular, report weight characters that are not printable ASCII
+ in octal form (<literal>\<replaceable>nnn</replaceable></literal>),
+ as <function>charout()</function> would render them. This avoids
+ possibly producing an invalidly-encoded error message.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [8bf257aeb] 2026-06-12 10:25:45 +0900
+Branch: REL_18_STABLE [4c777d6dd] 2026-06-12 10:25:49 +0900
+Branch: REL_17_STABLE [6c08cbb7a] 2026-06-12 10:25:51 +0900
+Branch: REL_16_STABLE [174076601] 2026-06-12 10:25:53 +0900
+Branch: REL_15_STABLE [1d8c72b2e] 2026-06-12 10:25:54 +0900
+Branch: REL_14_STABLE [41876c8d7] 2026-06-12 10:25:59 +0900
+Branch: master Release: REL_19_BR [0b74df66f] 2026-06-12 12:37:21 +0900
+Branch: REL_18_STABLE [0d145be2c] 2026-06-12 12:39:11 +0900
+Branch: REL_17_STABLE [940916549] 2026-06-12 12:39:17 +0900
+Branch: REL_16_STABLE [fac26fd41] 2026-06-12 12:39:22 +0900
+Branch: REL_15_STABLE [9618e790c] 2026-06-12 12:39:34 +0900
+Branch: REL_14_STABLE [a17f39aa2] 2026-06-12 12:39:40 +0900
+-->
+ <para>
+ Fix mishandling of namespace nodes in <function>xpath()</function>
+ (Michael Paquier)
+ <ulink url="&commit_baseurl;1d8c72b2e">§</ulink>
+ <ulink url="&commit_baseurl;9618e790c">§</ulink>
+ </para>
+
+ <para>
+ This fix avoids an unexpected <quote>could not copy node</quote>
+ error.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Langote <amitlan@postgresql.org>
+Branch: REL_16_STABLE [1daeef6e0] 2026-06-18 15:55:02 +0900
+Branch: REL_15_STABLE [8af173e28] 2026-06-18 15:54:16 +0900
+Branch: REL_14_STABLE [364014327] 2026-06-18 15:51:38 +0900
+-->
+ <para>
+ Treat an undefined jsonpath variable as an error even when no
+ variables are supplied (Andrey Rachitskiy)
+ <ulink url="&commit_baseurl;8af173e28">§</ulink>
+ </para>
+
+ <para>
+ The <type>jsonb</type> <literal>@?</literal>
+ and <literal>@@</literal> operators cannot supply any variables to
+ be used in their jsonpath expressions. This code path erroneously
+ treated an unknown jsonpath variable as a JSON null, rather than
+ raising an error as expected. Aside from not being the expected
+ behavior, this mistake could result in unbounded memory consumption.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [b4dfae2ff] 2026-08-04 17:59:13 +1200
+Branch: REL_19_STABLE [7746f7492] 2026-08-04 17:59:58 +1200
+Branch: REL_18_STABLE [6298a41b4] 2026-08-04 18:00:27 +1200
+Branch: REL_17_STABLE [1416f304d] 2026-08-04 18:00:49 +1200
+Branch: REL_16_STABLE [86f42357c] 2026-08-04 18:01:10 +1200
+Branch: REL_15_STABLE [d782c97e1] 2026-08-04 18:01:31 +1200
+Branch: REL_14_STABLE [fec40878c] 2026-08-04 18:01:55 +1200
+-->
+ <para>
+ Avoid machine-dependent behavior when dividing the smallest
+ possible <type>money</type> value by -1 (Andrey Rachitskiy)
+ <ulink url="&commit_baseurl;d782c97e1">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [4e68b7e29] 2026-08-02 16:49:17 -0400
+Branch: REL_19_STABLE [df8407d7d] 2026-08-02 16:49:18 -0400
+Branch: REL_18_STABLE [81b1e7916] 2026-08-02 16:49:18 -0400
+Branch: REL_17_STABLE [634a8dcb8] 2026-08-02 16:49:18 -0400
+Branch: REL_16_STABLE [83336e3ed] 2026-08-02 16:49:18 -0400
+Branch: REL_15_STABLE [025228104] 2026-08-02 16:49:18 -0400
+Branch: REL_14_STABLE [dda622edc] 2026-08-02 16:49:18 -0400
+-->
+ <para>
+ Fix crash after out-of-memory failure partway through creation of a
+ cache entry for a text search dictionary (Tom Lane)
+ <ulink url="&commit_baseurl;025228104">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [330a72052] 2026-08-02 13:22:39 -0400
+Branch: REL_19_STABLE [3fe4062cc] 2026-08-02 13:22:39 -0400
+Branch: REL_18_STABLE [4689ea9ce] 2026-08-02 13:22:39 -0400
+Branch: REL_17_STABLE [5fdea3aa3] 2026-08-02 13:22:39 -0400
+Branch: REL_16_STABLE [444038bb7] 2026-08-02 13:22:39 -0400
+Branch: REL_15_STABLE [0fb88979b] 2026-08-02 13:22:39 -0400
+Branch: REL_14_STABLE [cfc720ef4] 2026-08-02 13:22:39 -0400
+-->
+ <para>
+ Fix memory-safety bugs in processing of incorrect ispell/hunspell
+ dictionary files (Andrey Rachitskiy)
+ <ulink url="&commit_baseurl;0fb88979b">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Alexander Korotkov <akorotkov@postgresql.org>
+Branch: master [8a045f760] 2026-07-28 10:50:22 +0200
+Branch: REL_19_STABLE [70dad584e] 2026-07-28 10:50:53 +0200
+Branch: REL_18_STABLE [7becb647d] 2026-07-28 10:52:59 +0200
+Branch: REL_17_STABLE [ba5e46329] 2026-07-28 10:56:27 +0200
+Branch: REL_16_STABLE [006ac761e] 2026-07-28 10:56:34 +0200
+Branch: REL_15_STABLE [7123abab7] 2026-07-28 10:56:38 +0200
+Branch: REL_14_STABLE [15fd7a3e2] 2026-07-28 10:56:39 +0200
+-->
+ <para>
+ Honor query cancel and vacuum delay during GIN index posting-tree
+ cleanup (Paul Kim, Alexander Korotkov)
+ <ulink url="&commit_baseurl;7123abab7">§</ulink>
+ </para>
+
+ <para>
+ The posting tree for a common value can be large, so that this
+ missed check could allow vacuum to run for a long time before
+ noticing an interrupt.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Peter Geoghegan <pg@bowt.ie>
+Branch: master [c9ea37231] 2026-07-17 15:53:10 -0400
+Branch: REL_19_STABLE [1d4c81ad6] 2026-07-17 15:53:07 -0400
+Branch: REL_18_STABLE [959b7fa2c] 2026-07-17 15:53:05 -0400
+Branch: REL_17_STABLE [355faed5a] 2026-07-17 15:53:02 -0400
+Branch: REL_16_STABLE [e58192546] 2026-07-17 15:53:00 -0400
+Branch: REL_15_STABLE [126141425] 2026-07-17 15:52:58 -0400
+Branch: REL_14_STABLE [e4ad22eb0] 2026-07-17 15:52:56 -0400
+-->
+ <para>
+ Fix possible mis-decoding of index tuples during GiST and SP-GiST
+ index-only scans (Peter Geoghegan)
+ <ulink url="&commit_baseurl;126141425">§</ulink>
+ </para>
+
+ <para>
+ This error could lead to emitting corrupted data from an index-only
+ scan plan. The only affected core opclass is GiST's range_ops, and
+ it could only fail if the range column were not the first index
+ column.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_19_BR [f25a07b2d] 2026-06-19 12:52:00 -0400
+Branch: REL_18_STABLE [aa80c34c8] 2026-06-19 12:52:00 -0400
+Branch: REL_17_STABLE [f0a831ef3] 2026-06-19 12:52:00 -0400
+Branch: REL_16_STABLE [9951e3d38] 2026-06-19 12:52:00 -0400
+Branch: REL_15_STABLE [4647ac142] 2026-06-19 12:52:00 -0400
+Branch: REL_14_STABLE [4b3bc6b71] 2026-06-19 12:52:00 -0400
+-->
+ <para>
+ When creating directories, tolerate concurrent creation of the same
+ directory (Andrew Dunstan, Tom Lane)
+ <ulink url="&commit_baseurl;4647ac142">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master Release: REL_19_BR [2fbb21170] 2026-05-27 18:41:14 +0300
+Branch: REL_18_STABLE [c8cd3d697] 2026-05-27 18:36:28 +0300
+Branch: REL_17_STABLE [3a9909eda] 2026-05-27 18:36:51 +0300
+Branch: REL_16_STABLE [d9bc0d96c] 2026-05-27 18:37:12 +0300
+Branch: REL_15_STABLE [5fa137727] 2026-05-27 18:37:32 +0300
+Branch: REL_14_STABLE [5100bdbd3] 2026-05-27 18:37:56 +0300
+Branch: master Release: REL_19_BR [fd93ee100] 2026-05-27 18:41:03 +0300
+Branch: REL_18_STABLE [f9d5a52da] 2026-05-27 18:36:25 +0300
+Branch: REL_17_STABLE [c1588f92a] 2026-05-27 18:36:46 +0300
+Branch: REL_16_STABLE [d44cd4674] 2026-05-27 18:37:04 +0300
+Branch: REL_15_STABLE [ef3d7b15e] 2026-05-27 18:37:27 +0300
+Branch: REL_14_STABLE [36b6ed260] 2026-05-27 18:37:48 +0300
+-->
+ <para>
+ Prevent creation of dangling object dependencies by acquiring a
+ shared lock on any object being depended on (Bertrand Drouvot)
+ <ulink url="&commit_baseurl;5fa137727">§</ulink>
+ <ulink url="&commit_baseurl;ef3d7b15e">§</ulink>
+ </para>
+
+ <para>
+ The shared lock will conflict with any attempt to drop the
+ depended-on object, eliminating the race condition that formerly
+ existed. For example, if one session drops a schema (that appears
+ empty to it) concurrently with some other session creating a
+ function in that schema, previously both transactions could commit,
+ leaving an invalid function definition behind. Now, one transaction
+ or the other will fail.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Peter Geoghegan <pg@bowt.ie>
+Branch: master [ce3f19e26] 2026-07-25 12:01:35 -0400
+Branch: REL_19_STABLE [2aa3c6d1f] 2026-07-25 12:01:34 -0400
+Branch: REL_18_STABLE [d560e730e] 2026-07-25 12:01:32 -0400
+Branch: REL_17_STABLE [8434c9385] 2026-07-25 12:01:30 -0400
+Branch: REL_16_STABLE [e321faaae] 2026-07-25 12:01:28 -0400
+Branch: REL_15_STABLE [5d18105ca] 2026-07-25 12:01:26 -0400
+Branch: REL_14_STABLE [2fc3e1b44] 2026-07-25 12:01:24 -0400
+-->
+ <para>
+ Fix race condition in conflict detection
+ for <literal>SERIALIZABLE</literal> isolation mode
+ (Peter Geoghegan)
+ <ulink url="&commit_baseurl;5d18105ca">§</ulink>
+ </para>
+
+ <para>
+ A conflict could be missed when examining an initially-empty btree
+ index, allowing failure of serializability due to improperly
+ allowing conflicting transactions to commit.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Masahiko Sawada <msawada@postgresql.org>
+Branch: master Release: REL_19_BR [d79bf7612] 2026-05-27 16:25:56 -0700
+Branch: REL_18_STABLE [1a9b1cc18] 2026-05-27 16:25:59 -0700
+Branch: REL_17_STABLE [a651b8a89] 2026-05-27 16:26:02 -0700
+Branch: REL_16_STABLE [cdb9b2830] 2026-05-27 16:26:05 -0700
+Branch: REL_15_STABLE [159324a73] 2026-05-27 16:26:08 -0700
+-->
+ <para>
+ Fix race condition in ProcSignalBarrier code (Masahiko Sawada)
+ <ulink url="&commit_baseurl;159324a73">§</ulink>
+ </para>
+
+ <para>
+ This error could result in processes getting stuck, typically after
+ reporting <quote>still waiting for backend with
+ PID <replaceable>nnnn</replaceable> to accept
+ ProcSignalBarrier</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [563104523] 2026-05-27 14:48:56 +0900
+Branch: REL_18_STABLE [ae08eb168] 2026-05-27 14:48:59 +0900
+Branch: REL_17_STABLE [d489c4439] 2026-05-27 14:49:01 +0900
+Branch: REL_16_STABLE [65d04df60] 2026-05-27 14:49:02 +0900
+Branch: REL_15_STABLE [d5cc6df60] 2026-05-27 14:49:04 +0900
+Branch: REL_14_STABLE [8007d1185] 2026-05-27 14:52:31 +0900
+Branch: master Release: REL_19_BR [84b9d6bce] 2026-05-27 17:19:20 +0900
+Branch: REL_18_STABLE [12c9b8b42] 2026-05-27 17:19:53 +0900
+Branch: REL_17_STABLE [e14b4ea4a] 2026-05-27 17:19:55 +0900
+Branch: REL_16_STABLE [4e8edf53f] 2026-05-27 17:19:56 +0900
+Branch: REL_15_STABLE [e786fb5aa] 2026-05-27 17:19:58 +0900
+Branch: REL_14_STABLE [db4d12fc9] 2026-05-27 17:20:00 +0900
+-->
+ <para>
+ Fix race conditions when a set of processes that belong to the same
+ lock group exit at the same time (Vlad Lesin)
+ <ulink url="&commit_baseurl;d5cc6df60">§</ulink>
+ <ulink url="&commit_baseurl;e786fb5aa">§</ulink>
+ </para>
+
+ <para>
+ These errors could lead to PANIC aborts, with messages such
+ as <quote>latch already owned</quote>. The issue does not normally
+ arise in regular parallel query, since the leader won't exit before
+ seeing its workers finish; but some extensions reach the problem.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [c37b38806] 2026-05-23 08:10:07 +0900
+Branch: REL_18_STABLE [b903d1792] 2026-05-23 08:10:12 +0900
+Branch: REL_17_STABLE [c89499a79] 2026-05-23 08:10:14 +0900
+Branch: REL_16_STABLE [e037a4199] 2026-05-23 08:10:15 +0900
+Branch: REL_15_STABLE [065cbfb88] 2026-05-23 08:10:17 +0900
+Branch: REL_14_STABLE [e18b77153] 2026-05-23 08:10:18 +0900
+-->
+ <para>
+ Avoid exposing a WAL receiver's full connection string during timeline
+ jumps (Chao Li)
+ <ulink url="&commit_baseurl;065cbfb88">§</ulink>
+ </para>
+
+ <para>
+ The <structname>pg_stat_wal_receiver</structname> view should show a
+ sanitized version of the connection string, without sensitive data.
+ But it transiently showed the full string when we re-use an existing
+ WAL receiver.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master Release: REL_19_BR [bf7d19be9] 2026-05-16 18:01:35 -0700
+Branch: REL_18_STABLE [dc3db3a83] 2026-05-16 18:01:38 -0700
+Branch: REL_17_STABLE [15f4e3d0c] 2026-05-16 18:01:39 -0700
+Branch: REL_16_STABLE [59759e1a5] 2026-05-16 18:01:39 -0700
+Branch: REL_15_STABLE [871d4f5b6] 2026-05-16 18:01:40 -0700
+Branch: REL_14_STABLE [510a05f07] 2026-05-16 18:01:46 -0700
+-->
+ <para>
+ Use run-time checks, not just Asserts, to verify the correct number
+ of columns in tuples received during logical replication (Varik
+ Matevosyan)
+ <ulink url="&commit_baseurl;871d4f5b6">§</ulink>
+ </para>
+
+ <para>
+ A malicious or buggy publisher could send inconsistent numbers of
+ columns. While we could not find a scenario in which this would
+ have serious ill effects, extra caution seems warranted.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_19_BR [a75bd485b] 2026-06-15 15:35:37 -0400
+Branch: REL_18_STABLE [abb582555] 2026-06-15 15:35:37 -0400
+Branch: REL_17_STABLE [14810cc0d] 2026-06-15 15:35:37 -0400
+Branch: REL_16_STABLE [26d6c19d0] 2026-06-15 15:35:37 -0400
+Branch: REL_15_STABLE [819e5b964] 2026-06-15 15:35:37 -0400
+Branch: REL_14_STABLE [2a00840e8] 2026-06-15 15:35:37 -0400
+-->
+ <para>
+ Clean up quoting of string parameters within constructed replication
+ commands (Tom Lane)
+ <ulink url="&commit_baseurl;819e5b964">§</ulink>
+ </para>
+
+ <para>
+ Various places that generate replication commands were not being
+ adequately careful about quoting replication slot names and other
+ parameters that need to be inserted into those commands. This could
+ result in unexpected syntax errors in those commands. In principle,
+ a crafted replication slot name could result in SQL injection; but
+ such a scenario seems very unlikely to occur in practice, since
+ replication operations can only be invoked by highly-privileged
+ users and there is no reason for them to use a slot name coming from
+ an untrustworthy source.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Masahiko Sawada <msawada@postgresql.org>
+Branch: master [acaa100f9] 2026-07-28 12:33:28 -0700
+Branch: REL_19_STABLE [2289e65e1] 2026-07-28 12:33:31 -0700
+Branch: REL_18_STABLE [b563fc6bd] 2026-07-28 12:33:35 -0700
+Branch: REL_17_STABLE [8c4519c71] 2026-07-28 12:33:40 -0700
+Branch: REL_16_STABLE [744618346] 2026-07-28 12:33:43 -0700
+Branch: REL_15_STABLE [0dbfb8520] 2026-07-28 12:33:47 -0700
+Branch: REL_14_STABLE [c2d34db0a] 2026-07-28 12:33:50 -0700
+-->
+ <para>
+ Fix logical decoding of empty prepared transactions (Masahiko Sawada)
+ <ulink url="&commit_baseurl;0dbfb8520">§</ulink>
+ </para>
+
+ <para>
+ A prepared transaction that did not cause any decodable updates could
+ result in sending <command>COMMIT/ROLLBACK PREPARED</command> to the
+ output plugin with no preceding <command>PREPARE</command>. For the
+ built-in subscriber this breaks replication, and other plugins will
+ probably not like it either.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [8e684ce11] 2026-06-30 08:48:47 +0900
+Branch: REL_19_STABLE [22af34b98] 2026-06-30 08:50:08 +0900
+Branch: REL_18_STABLE [627605713] 2026-06-30 08:50:50 +0900
+Branch: REL_17_STABLE [a1ed6a9a0] 2026-06-30 08:51:22 +0900
+Branch: REL_16_STABLE [913d3b610] 2026-06-30 08:51:51 +0900
+Branch: REL_15_STABLE [d2980067b] 2026-06-30 08:52:50 +0900
+-->
+ <para>
+ Fix corruption of unlogged sequences after standby promotion
+ (Fujii Masao)
+ <ulink url="&commit_baseurl;d2980067b">§</ulink>
+ </para>
+
+ <para>
+ Previously, if an unlogged sequence was created on the primary and
+ replicated to a standby, accessing the sequence after promoting the
+ standby could fail with <quote>bad magic number in sequence</quote>
+ or related errors.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+Branch: master [b614de487] 2026-07-29 17:15:45 +0200
+Branch: REL_19_STABLE [bef46aed3] 2026-07-29 17:15:45 +0200
+Branch: REL_18_STABLE [331016322] 2026-07-29 17:15:45 +0200
+Branch: REL_17_STABLE [2cf28d1b9] 2026-07-29 17:15:45 +0200
+Branch: REL_16_STABLE [5dbeb69bc] 2026-07-29 17:15:45 +0200
+Branch: REL_15_STABLE [8f64cc83f] 2026-07-29 17:15:45 +0200
+Branch: REL_14_STABLE [5fb3c6389] 2026-07-29 17:15:45 +0200
+-->
+ <para>
+ Fix cascading standby reconnect failure after archive fallback
+ (Marco Nenciarini)
+ <ulink url="&commit_baseurl;8f64cc83f">§</ulink>
+ </para>
+
+ <para>
+ A cascading standby could fail to reconnect to its upstream standby
+ with <quote>requested starting point ... is ahead of the WAL flush
+ position</quote> after falling back to archive recovery.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master Release: REL_19_BR [f2081a780] 2026-06-03 18:44:56 +0900
+Branch: REL_18_STABLE [f833c9207] 2026-06-03 18:46:49 +0900
+Branch: REL_17_STABLE [080d61f07] 2026-06-03 18:47:10 +0900
+Branch: REL_16_STABLE [51e79222c] 2026-06-03 18:47:31 +0900
+Branch: REL_15_STABLE [a4eb59d40] 2026-06-03 18:47:46 +0900
+Branch: REL_14_STABLE [968c50845] 2026-06-03 18:47:52 +0900
+-->
+ <para>
+ Avoid race condition while dropping ephemeral replication slots
+ (Zhijie Hou)
+ <ulink url="&commit_baseurl;a4eb59d40">§</ulink>
+ </para>
+
+ <para>
+ The slot-releasing code performed some additional updates to the
+ replication slot's shared-memory entry after releasing the slot.
+ This is unsafe since another session could immediately re-use the
+ dropped slot's shared-memory entry. Skip those updates in the case
+ of an ephemeral slot.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master Release: REL_19_BR [422e54e30] 2026-05-13 11:44:31 +0900
+Branch: REL_18_STABLE [d9cd9b4d7] 2026-05-13 11:46:08 +0900
+Branch: REL_17_STABLE [f2acab534] 2026-05-13 11:46:12 +0900
+Branch: REL_16_STABLE [d140237da] 2026-05-13 11:46:17 +0900
+Branch: REL_15_STABLE [b5f7e7569] 2026-05-13 11:46:21 +0900
+Branch: REL_14_STABLE [e3c4e3746] 2026-05-13 11:46:26 +0900
+-->
+ <para>
+ Fix stale progress reports during logical replication table
+ synchronization (Shinya Kato)
+ <ulink url="&commit_baseurl;b5f7e7569">§</ulink>
+ </para>
+
+ <para>
+ Previously, the <structname>pg_stat_progress_copy</structname> view
+ in the subscriber would continue to show the
+ initial <command>COPY</command> operation as active even after the
+ data copy had finished. The stale entry remained visible until
+ synchronization caught up with the publisher.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [55f0a13e9] 2026-07-01 23:04:18 +0900
+Branch: REL_19_STABLE [b70000837] 2026-07-01 23:05:04 +0900
+Branch: REL_18_STABLE [e7564ee8c] 2026-07-01 23:05:12 +0900
+Branch: REL_17_STABLE [e2ea6bfed] 2026-07-01 23:05:34 +0900
+Branch: REL_16_STABLE [7cbd80340] 2026-07-01 23:06:43 +0900
+Branch: REL_15_STABLE [cf7530cf7] 2026-07-01 23:06:49 +0900
+Branch: REL_18_STABLE [e2ad214dd] 2026-07-06 09:46:15 +0900
+Branch: REL_17_STABLE [a240e8cd2] 2026-07-06 09:47:56 +0900
+Branch: REL_16_STABLE [fffa4d870] 2026-07-06 09:48:01 +0900
+Branch: REL_15_STABLE [a8fb98b7b] 2026-07-06 09:48:06 +0900
+-->
+ <para>
+ Clear base backup progress on backup failure (Chao Li)
+ <ulink url="&commit_baseurl;cf7530cf7">§</ulink>
+ <ulink url="&commit_baseurl;a8fb98b7b">§</ulink>
+ </para>
+
+ <para>
+ Previously the <structname>pg_stat_progress_basebackup</structname>
+ view would continue to show a stale progress entry after a failure,
+ until the replication client
+ disconnected. <application>pg_basebackup</application> normally
+ disconnects immediately, but other clients might not.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [850b9218c] 2026-06-18 11:49:30 +0900
+Branch: REL_18_STABLE [5cc59834b] 2026-06-18 11:49:34 +0900
+Branch: REL_17_STABLE [2e0c61aed] 2026-06-18 11:49:36 +0900
+Branch: REL_16_STABLE [bf4616b59] 2026-06-18 11:49:39 +0900
+Branch: REL_15_STABLE [1e9e62193] 2026-06-18 11:49:41 +0900
+Branch: REL_18_STABLE [8a4f389dd] 2026-06-18 14:48:37 +0900
+Branch: REL_17_STABLE [39e649d44] 2026-06-18 14:48:40 +0900
+Branch: REL_16_STABLE [7c457ea15] 2026-06-18 14:48:42 +0900
+Branch: REL_15_STABLE [75aca8b93] 2026-06-18 14:48:43 +0900
+Branch: REL_18_STABLE [fe464e9e6] 2026-06-23 07:58:04 +0900
+Branch: REL_17_STABLE [afb076b29] 2026-06-23 07:59:00 +0900
+Branch: REL_16_STABLE [e34b1ff5d] 2026-06-23 07:59:02 +0900
+Branch: REL_15_STABLE [9e4771825] 2026-06-23 07:59:03 +0900
+-->
+ <para>
+ Fix possible PANIC due to concurrent drop of pgstats entries
+ when <varname>track_functions</varname> is enabled (Sami Imseih,
+ Michael Paquier)
+ <ulink url="&commit_baseurl;1e9e62193">§</ulink>
+ <ulink url="&commit_baseurl;75aca8b93">§</ulink>
+ <ulink url="&commit_baseurl;9e4771825">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [4069df21b] 2026-08-07 14:23:28 +0900
+Branch: REL_19_STABLE [89fc6a7c1] 2026-08-07 14:23:33 +0900
+Branch: REL_18_STABLE [2fd8d45ec] 2026-08-07 14:23:35 +0900
+Branch: REL_17_STABLE [fc9283b21] 2026-08-07 14:23:36 +0900
+Branch: REL_16_STABLE [636bcd6a5] 2026-08-07 14:23:38 +0900
+Branch: REL_15_STABLE [10e20e59e] 2026-08-07 14:23:39 +0900
+-->
+ <para>
+ Clean up broken local pgstats entry after failing to obtain space for
+ the corresponding shared hashtable entry (Niall Newman)
+ <ulink url="&commit_baseurl;10e20e59e">§</ulink>
+ </para>
+
+ <para>
+ Failure to do this led to a null-pointer dereference the next time
+ the local entry was used.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master Release: REL_19_BR [4015abe14] 2026-06-24 09:09:48 +0900
+Branch: REL_18_STABLE [e430ecc59] 2026-06-24 09:11:56 +0900
+Branch: REL_17_STABLE [d424d06ed] 2026-06-24 09:14:06 +0900
+Branch: REL_16_STABLE [3854f4afc] 2026-06-24 09:15:08 +0900
+Branch: REL_15_STABLE [9b2a6ccc4] 2026-06-24 09:16:24 +0900
+Branch: REL_14_STABLE [e520ad34b] 2026-06-24 09:17:36 +0900
+-->
+ <para>
+ In <application>PL/Perl</application>, avoid NULL pointer
+ dereference crash when working with an
+ invalid <type>PostgreSQL::InServer::ARRAY</type> object (Xing Guo)
+ <ulink url="&commit_baseurl;9b2a6ccc4">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master Release: REL_19_BR [8612f0b7c] 2026-06-29 11:38:39 +0900
+Branch: REL_18_STABLE [53482fcb9] 2026-06-29 11:39:50 +0900
+Branch: REL_17_STABLE [3dc59c173] 2026-06-29 11:40:49 +0900
+Branch: REL_16_STABLE [e92f23bde] 2026-06-29 11:41:50 +0900
+Branch: REL_15_STABLE [12bff46ff] 2026-06-29 11:43:26 +0900
+Branch: REL_14_STABLE [0b7719f74] 2026-06-29 11:44:35 +0900
+Branch: REL_14_STABLE [309dc4526] 2026-06-29 14:21:15 +0900
+-->
+ <para>
+ In <application>PL/Python</application>, properly check for errors
+ when working with sequence and mapping objects (Richard Guo)
+ <ulink url="&commit_baseurl;12bff46ff">§</ulink>
+ </para>
+
+ <para>
+ Previously, a broken object or an unhandled exception could result
+ in a NULL pointer dereference crash.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [ffd080d94] 2026-07-07 18:45:34 +0300
+Branch: REL_19_STABLE [eeb2940ae] 2026-07-07 18:46:10 +0300
+Branch: REL_18_STABLE [2167302b7] 2026-07-07 18:46:24 +0300
+Branch: REL_17_STABLE [c162810a5] 2026-07-07 18:46:58 +0300
+Branch: REL_16_STABLE [d3f329656] 2026-07-07 18:47:07 +0300
+Branch: REL_15_STABLE [4ecba7fa3] 2026-07-07 18:53:51 +0300
+Branch: REL_14_STABLE [1b018b5d1] 2026-07-07 18:54:09 +0300
+Branch: master [343594a26] 2026-07-07 18:45:37 +0300
+Branch: REL_19_STABLE [7f8745543] 2026-07-07 18:46:14 +0300
+Branch: REL_18_STABLE [bb0a54518] 2026-07-07 18:46:33 +0300
+Branch: REL_17_STABLE [177a2a2e3] 2026-07-07 18:46:58 +0300
+Branch: REL_16_STABLE [477bc27a5] 2026-07-07 18:47:07 +0300
+Branch: REL_15_STABLE [05908afcd] 2026-07-07 18:53:52 +0300
+Branch: REL_14_STABLE [d3888c90a] 2026-07-07 18:54:09 +0300
+Branch: master [d293f0345] 2026-07-09 18:34:24 +0300
+Branch: REL_19_STABLE [536512f34] 2026-07-09 18:34:53 +0300
+Branch: REL_18_STABLE [27761c015] 2026-07-09 18:35:12 +0300
+Branch: REL_17_STABLE [0958c3ea4] 2026-07-09 18:35:24 +0300
+Branch: REL_16_STABLE [6243ea6c3] 2026-07-09 18:35:37 +0300
+Branch: REL_15_STABLE [21a6c69ea] 2026-07-09 18:35:47 +0300
+Branch: REL_14_STABLE [f5f569713] 2026-07-09 18:36:30 +0300
+Branch: master [17accbe0f] 2026-07-09 18:34:27 +0300
+Branch: REL_19_STABLE [d9eb70c9c] 2026-07-09 18:34:53 +0300
+Branch: REL_18_STABLE [87c3a79ea] 2026-07-09 18:35:12 +0300
+Branch: REL_17_STABLE [bab0a2db7] 2026-07-09 18:35:24 +0300
+Branch: REL_16_STABLE [56988064b] 2026-07-09 18:35:37 +0300
+Branch: REL_15_STABLE [5ba13f8c0] 2026-07-09 18:36:18 +0300
+Branch: REL_14_STABLE [7532f2117] 2026-07-09 18:36:41 +0300
+-->
+ <para>
+ In <application>libpq</application>, always drain all pending bytes
+ from the SSL or GSS decryption buffer
+ during <function>pqReadData()</function> (Jacob Champion)
+ <ulink url="&commit_baseurl;4ecba7fa3">§</ulink>
+ <ulink url="&commit_baseurl;05908afcd">§</ulink>
+ <ulink url="&commit_baseurl;21a6c69ea">§</ulink>
+ <ulink url="&commit_baseurl;5ba13f8c0">§</ulink>
+ </para>
+
+ <para>
+ This avoids edge cases where <application>libpq</application> or its
+ calling application waits for more data to arrive on the socket, but
+ actually all the data has already arrived.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master Release: REL_19_BR [e0511883c] 2026-06-15 11:28:45 +0300
+Branch: REL_18_STABLE [b1ab4bc52] 2026-06-15 11:35:20 +0300
+Branch: REL_17_STABLE [e4183c667] 2026-06-15 11:35:41 +0300
+Branch: REL_16_STABLE [8d516d2b9] 2026-06-15 11:38:07 +0300
+Branch: REL_15_STABLE [0f63b74a4] 2026-06-15 11:38:30 +0300
+Branch: REL_14_STABLE [1b79c8d1a] 2026-06-15 11:38:40 +0300
+-->
+ <para>
+ Allow <application>libpq</application> to accept
+ ParameterDescription messages exceeding 30000 bytes (Ning Sun)
+ <ulink url="&commit_baseurl;0f63b74a4">§</ulink>
+ </para>
+
+ <para>
+ Previously, this message type was not among those
+ that <application>libpq</application>'s validity heuristics believed
+ could be long. The limit resulted in failure for prepared queries
+ having more than 7498 parameters, which is unlikely but supported.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master Release: REL_19_BR [4484165b0] 2026-06-08 17:09:46 +0900
+Branch: REL_18_STABLE [081434b0f] 2026-06-08 17:10:25 +0900
+Branch: REL_17_STABLE [fe8c0a762] 2026-06-08 17:11:12 +0900
+Branch: REL_16_STABLE [4d4b73cfd] 2026-06-08 17:14:10 +0900
+Branch: REL_15_STABLE [bfeddcf09] 2026-06-08 17:14:15 +0900
+Branch: REL_14_STABLE [9e8fd9f7a] 2026-06-08 17:14:20 +0900
+-->
+ <para>
+ Reject multiple descriptor header items
+ in <application>ecpg</application>'s <literal>GET/SET
+ DESCRIPTOR</literal> statements (Masashi Kamura)
+ <ulink url="&commit_baseurl;bfeddcf09">§</ulink>
+ </para>
+
+ <para>
+ Previously the grammar allowed this syntax, but broken C code was
+ generated. Adjust the grammar and the documentation to allow only
+ one header item.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [3d0d6741d] 2026-06-08 14:37:51 +0900
+Branch: REL_18_STABLE [07a6c262b] 2026-06-08 14:37:56 +0900
+Branch: REL_17_STABLE [efd885d05] 2026-06-08 14:37:57 +0900
+Branch: REL_16_STABLE [1edbe6695] 2026-06-08 14:37:59 +0900
+Branch: REL_15_STABLE [022ba5c61] 2026-06-08 14:38:00 +0900
+Branch: REL_14_STABLE [a4ca91ea1] 2026-06-08 14:38:01 +0900
+-->
+ <para>
+ Make line widths match in <application>psql</application>'s expanded
+ aligned output format (Pavel Stehule)
+ <ulink url="&commit_baseurl;022ba5c61">§</ulink>
+ </para>
+
+ <para>
+ When the table's data rows are narrower than the record header lines,
+ widen the data rows to match the headers, avoiding unsightly output.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [38afc3dcb] 2026-07-25 19:08:27 +0900
+Branch: REL_19_STABLE [77aeca802] 2026-07-25 19:09:19 +0900
+Branch: REL_18_STABLE [f2d6cf880] 2026-07-25 19:10:15 +0900
+Branch: REL_17_STABLE [41949c6f3] 2026-07-25 19:10:22 +0900
+Branch: REL_16_STABLE [844bc718a] 2026-07-25 19:10:28 +0900
+Branch: REL_15_STABLE [e6e8a3078] 2026-07-25 19:10:49 +0900
+Branch: REL_14_STABLE [4e19081da] 2026-07-25 19:11:34 +0900
+-->
+ <para>
+ Fix <application>psql</application>'s privilege check for showing
+ database size in <command>\l+</command> (Christoph Berg)
+ <ulink url="&commit_baseurl;e6e8a3078">§</ulink>
+ </para>
+
+ <para>
+ The underlying server function permits users who
+ have <literal>pg_read_all_stats</literal> privileges to see the
+ sizes of all databases, even if they lack <literal>CONNECT</literal>
+ privilege. But <application>psql</application> was unaware of that
+ provision and would not call the function unless the user
+ has <literal>CONNECT</literal> privilege.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [6d4ca6de9] 2026-07-03 13:48:59 +0900
+Branch: REL_19_STABLE [558e0de6d] 2026-07-03 13:50:01 +0900
+Branch: REL_18_STABLE [598af79b1] 2026-07-03 13:50:08 +0900
+Branch: REL_17_STABLE [355a4fcf9] 2026-07-03 13:50:15 +0900
+Branch: REL_16_STABLE [f9afdb6d1] 2026-07-03 13:50:20 +0900
+Branch: REL_15_STABLE [c25737c89] 2026-07-03 13:50:26 +0900
+Branch: REL_14_STABLE [2d44bb900] 2026-07-03 13:50:51 +0900
+-->
+ <para>
+ Fix <application>psql</application>'s tab completion
+ for <command>\df</command> to consider procedures too
+ (Erik Wienhold)
+ <ulink url="&commit_baseurl;c25737c89">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master Release: REL_19_BR [61f8a85a5] 2026-05-14 12:30:34 +0900
+Branch: REL_18_STABLE [98dd6c204] 2026-05-14 12:31:14 +0900
+Branch: REL_17_STABLE [52b3e7001] 2026-05-14 12:31:19 +0900
+Branch: REL_16_STABLE [6432a4cd6] 2026-05-14 12:31:25 +0900
+Branch: REL_15_STABLE [f18fcd9a4] 2026-05-14 12:31:43 +0900
+-->
+ <para>
+ Fix thread-safety bug in <application>pgbench</application>
+ (Fujii Masao)
+ <ulink url="&commit_baseurl;f18fcd9a4">§</ulink>
+ </para>
+
+ <para>
+ When <application>pgbench</application> runs with multiple threads
+ and the <option>--verbose-errors</option> option, different threads
+ could attempt to use the same buffer to construct error messages,
+ leading to corrupted log output.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master Release: REL_19_BR [263d1e6df] 2026-05-20 15:54:13 +0900
+Branch: REL_18_STABLE [89b4b3ae3] 2026-05-20 15:56:58 +0900
+Branch: REL_17_STABLE [ddd12d1a5] 2026-05-20 15:57:04 +0900
+Branch: REL_16_STABLE [9590dcfca] 2026-05-20 15:57:09 +0900
+Branch: REL_15_STABLE [ba9833a75] 2026-05-20 15:57:14 +0900
+Branch: REL_14_STABLE [5552a15a3] 2026-05-20 15:57:19 +0900
+-->
+ <para>
+ Use the source cluster's group-read file permissions
+ for <application>pg_recvlogical</application> output files
+ (Fujii Masao)
+ <ulink url="&commit_baseurl;ba9833a75">§</ulink>
+ </para>
+
+ <para>
+ <application>pg_recvlogical</application> was documented to behave
+ this way, but it never actually enabled group-read.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Alexander Korotkov <akorotkov@postgresql.org>
+Branch: master Release: REL_19_BR [da1eff08a] 2026-06-14 04:04:48 +0300
+Branch: REL_18_STABLE [897e79486] 2026-06-14 04:05:50 +0300
+Branch: REL_17_STABLE [8abb8a155] 2026-06-14 04:07:00 +0300
+Branch: REL_16_STABLE [c89a1ca01] 2026-06-14 04:07:42 +0300
+Branch: REL_15_STABLE [4284476c0] 2026-06-14 04:08:00 +0300
+Branch: REL_14_STABLE [af09b18cb] 2026-06-14 04:06:43 +0300
+-->
+ <para>
+ In <filename>contrib/amcheck</filename>, handle short-header varlena
+ datums correctly (Andrey Borodin)
+ <ulink url="&commit_baseurl;4284476c0">§</ulink>
+ </para>
+
+ <para>
+ This error could result in doing excess work while verifying a btree
+ index, but seems not to have had any worse consequences.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [7d3448961] 2026-07-01 13:27:22 -0400
+Branch: REL_19_STABLE [a47005f0b] 2026-07-01 13:27:22 -0400
+Branch: REL_18_STABLE [1e1d07792] 2026-07-01 13:27:22 -0400
+Branch: REL_17_STABLE [d215d2cc2] 2026-07-01 13:27:22 -0400
+Branch: REL_16_STABLE [d569ccd40] 2026-07-01 13:27:22 -0400
+Branch: REL_15_STABLE [98dd4406f] 2026-07-01 13:27:22 -0400
+Branch: REL_14_STABLE [255bce448] 2026-07-01 13:27:22 -0400
+-->
+ <para>
+ In <filename>contrib/btree_gist</filename>,
+ fix <literal>NaN</literal> handling in the <type>float4</type>
+ and <type>float8</type> opclasses (Bill Kim, Tom Lane)
+ <ulink url="&commit_baseurl;98dd4406f">§</ulink>
+ </para>
+
+ <para>
+ Comparisons, as well as the GiST penalty and distance functions, did
+ not account for <literal>NaN</literal> and would give the wrong
+ answer when handed one. It is recommended to
+ reindex <filename>btree_gist</filename> indexes on float columns
+ after installing this update, if there is any possibility that there
+ are <literal>NaN</literal> entries in those columns.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [eef644e57] 2026-07-03 13:50:14 -0400
+Branch: REL_19_STABLE [fc6649abe] 2026-07-03 13:50:14 -0400
+Branch: REL_18_STABLE [12c519207] 2026-07-03 13:50:14 -0400
+Branch: REL_17_STABLE [86992769e] 2026-07-03 13:50:14 -0400
+Branch: REL_16_STABLE [0663382c9] 2026-07-03 13:50:14 -0400
+Branch: REL_15_STABLE [8f2a1b3d3] 2026-07-03 13:50:14 -0400
+Branch: REL_14_STABLE [286f9a3ce] 2026-07-03 13:50:14 -0400
+-->
+ <para>
+ In <filename>contrib/btree_gist</filename>, fix searches using a
+ not-equal operator (Ayush Tiwari)
+ <ulink url="&commit_baseurl;8f2a1b3d3">§</ulink>
+ </para>
+
+ <para>
+ For variable-length data types, the code for scanning non-leaf index
+ pages applied the wrong comparison function, leading to wrong
+ results and potentially crashes.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_19_BR [da82fbb8f] 2026-06-17 11:04:41 -0400
+Branch: REL_18_STABLE [e3b7a43fa] 2026-06-17 11:04:41 -0400
+Branch: REL_17_STABLE [3df0b7755] 2026-06-17 11:04:41 -0400
+Branch: REL_16_STABLE [b0f3465b6] 2026-06-17 11:04:41 -0400
+Branch: REL_15_STABLE [a6f23c3ad] 2026-06-17 11:04:41 -0400
+Branch: REL_14_STABLE [639fff511] 2026-06-17 11:04:41 -0400
+Branch: master Release: REL_19_BR [c0f17b04d] 2026-06-18 12:23:13 -0400
+Branch: REL_18_STABLE [d65cf6f80] 2026-06-18 12:22:55 -0400
+Branch: REL_17_STABLE [4efef9d18] 2026-06-18 12:22:55 -0400
+Branch: REL_16_STABLE [60a1d712a] 2026-06-18 12:22:55 -0400
+Branch: REL_15_STABLE [4fbbabb0a] 2026-06-18 12:22:55 -0400
+Branch: REL_14_STABLE [1f6b2295f] 2026-06-18 12:22:55 -0400
+-->
+ <para>
+ Fix unguarded recursion and loops in
+ <filename>contrib/hstore_plperl</filename>,
+ <filename>contrib/jsonb_plperl</filename>, and
+ <filename>contrib/jsonb_plpython</filename>
+ (Aleksander Alekseev)
+ <ulink url="&commit_baseurl;a6f23c3ad">§</ulink>
+ <ulink url="&commit_baseurl;4fbbabb0a">§</ulink>
+ </para>
+
+ <para>
+ Prevent stack overflow when dealing with deeply
+ nested <type>jsonb</type> values, and allow interruption of the infinite
+ loop caused when attempting to dereference circular chains of Perl
+ object references.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master Release: REL_19_BR [524cc0f63] 2026-05-25 18:15:49 -0400
+Branch: REL_18_STABLE [e7544c518] 2026-05-25 18:15:49 -0400
+Branch: REL_17_STABLE [94b57ab54] 2026-05-25 18:15:49 -0400
+Branch: REL_16_STABLE [273be484a] 2026-05-25 18:15:49 -0400
+Branch: REL_15_STABLE [702a6d5f6] 2026-05-25 18:15:49 -0400
+Branch: REL_14_STABLE [a96b051a9] 2026-05-25 18:15:49 -0400
+-->
+ <para>
+ Fix missed release of statistics catcache entry
+ in <filename>contrib/intarray</filename> (Man Zeng)
+ <ulink url="&commit_baseurl;702a6d5f6">§</ulink>
+ </para>
+
+ <para>
+ This oversight led to warnings like <quote>resource was not closed:
+ cache pg_statistic</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master Release: REL_19_BR [3f3280491] 2026-06-16 09:29:47 +0300
+Branch: REL_18_STABLE [c3e36a9a5] 2026-06-16 09:31:08 +0300
+Branch: REL_17_STABLE [c391c00d9] 2026-06-16 09:31:12 +0300
+Branch: REL_16_STABLE [aca944e33] 2026-06-16 09:31:17 +0300
+Branch: REL_15_STABLE [1bec6b1c1] 2026-06-16 09:31:20 +0300
+Branch: REL_14_STABLE [f528a5606] 2026-06-16 09:31:23 +0300
+-->
+ <para>
+ In <filename>contrib/ltree</filename>, fix integer overflow in
+ comparisons (Ayush Tiwari)
+ <ulink url="&commit_baseurl;1bec6b1c1">§</ulink>
+ </para>
+
+ <para>
+ <type>ltree</type> values containing more than about 14,653 labels
+ resulted in wrong comparison answers due to overflow. If a btree
+ index contains such values, it is probably corrupt and should be
+ reindexed after installing this update.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [193a4ded9] 2026-06-06 08:16:36 +0900
+Branch: REL_18_STABLE [2b09f8a91] 2026-06-06 08:16:40 +0900
+Branch: REL_17_STABLE [0bcf19c9e] 2026-06-06 08:16:41 +0900
+Branch: REL_16_STABLE [daf8bc7d4] 2026-06-06 08:16:43 +0900
+Branch: REL_15_STABLE [51f63ba2b] 2026-06-06 08:16:44 +0900
+Branch: REL_14_STABLE [1eda3eb07] 2026-06-06 08:16:46 +0900
+-->
+ <para>
+ Fix array overrun in <filename>contrib/pg_surgery</filename>'s
+ <function>heap_force_kill</function> and
+ <function>heap_force_freeze</function> functions (Michael Paquier)
+ <ulink url="&commit_baseurl;51f63ba2b">§</ulink>
+ </para>
+
+ <para>
+ Attempting to change a TID whose offset number equals
+ MaxHeapTuplesPerPage wrote one byte past the end of the allocated
+ array, potentially crashing the server.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+Branch: master [346fbdcc2] 2026-08-04 11:44:11 +0200
+Branch: REL_19_STABLE [1f24c8237] 2026-08-04 11:44:11 +0200
+Branch: REL_18_STABLE [19f0391df] 2026-08-04 11:44:11 +0200
+Branch: REL_17_STABLE [1b6c99d96] 2026-08-04 11:44:11 +0200
+Branch: REL_16_STABLE [eb28b6f24] 2026-08-04 11:44:11 +0200
+Branch: REL_15_STABLE [395700f48] 2026-08-04 11:44:11 +0200
+Branch: REL_14_STABLE [e9d53cf45] 2026-08-04 11:44:11 +0200
+-->
+ <para>
+ In <filename>contrib/pg_surgery</filename>, avoid infinite loop with
+ TID arrays having more than 64K elements (Andrey Rachitskiy)
+ <ulink url="&commit_baseurl;395700f48">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master Release: REL_19_BR [611756948] 2026-05-14 13:11:49 -0500
+Branch: REL_18_STABLE [ed0c4d5af] 2026-05-14 13:11:49 -0500
+Branch: REL_17_STABLE [6b4de201e] 2026-05-14 13:11:49 -0500
+Branch: REL_16_STABLE [eb93f10e2] 2026-05-14 13:11:49 -0500
+Branch: REL_15_STABLE [77b2d18e9] 2026-05-14 13:11:49 -0500
+Branch: REL_14_STABLE [1de0a711d] 2026-05-14 13:11:49 -0500
+-->
+ <para>
+ Avoid NULL-pointer dereference
+ in <filename>contrib/refint</filename>'s
+ <function>check_foreign_key()</function> (Ayush Tiwari)
+ <ulink url="&commit_baseurl;77b2d18e9">§</ulink>
+ </para>
+
+ <para>
+ In the on-update-cascade case, a null value of a referenced column
+ led to a crash. This is an oversight in the fix for CVE-2026-6637,
+ but the code that was there before that wasn't really right either.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master Release: REL_19_BR [1fbe2066d] 2026-06-05 12:08:05 -0500
+Branch: REL_18_STABLE [79a506228] 2026-06-05 12:08:05 -0500
+Branch: REL_17_STABLE [66a5146dc] 2026-06-05 12:08:05 -0500
+Branch: REL_16_STABLE [a572dd213] 2026-06-05 12:08:05 -0500
+Branch: REL_15_STABLE [b7b513d9a] 2026-06-05 12:08:05 -0500
+Branch: REL_14_STABLE [5b72d0279] 2026-06-05 12:08:05 -0500
+-->
+ <para>
+ Remove the plan cache in <filename>contrib/refint</filename>
+ (Ayush Tiwari)
+ <ulink url="&commit_baseurl;b7b513d9a">§</ulink>
+ </para>
+
+ <para>
+ This caching behavior has several serious bugs, notably that
+ <function>check_foreign_key()</function> embeds the new key values
+ in its cascade-UPDATE queries, so a cached plan reuses the
+ originally-needed values rather than the key values that should be
+ used. The simplest solution is to remove it.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master Release: REL_19_BR [0e1f1ed15] 2026-06-11 12:33:48 +0300
+Branch: REL_18_STABLE [0004cab4d] 2026-06-11 12:34:26 +0300
+Branch: REL_17_STABLE [bcbbd070d] 2026-06-11 12:34:32 +0300
+Branch: REL_16_STABLE [504ca0513] 2026-06-11 12:34:37 +0300
+Branch: REL_15_STABLE [b3aa2083a] 2026-06-11 12:34:42 +0300
+Branch: REL_14_STABLE [58b91fc73] 2026-06-11 12:34:45 +0300
+-->
+ <para>
+ Fix <filename>contrib/seg</filename> to print segments
+ with <literal>~</literal> certainty indicators correctly
+ (Ewan Young)
+ <ulink url="&commit_baseurl;b3aa2083a">§</ulink>
+ </para>
+
+ <para>
+ Due to a typo, <function>seg_out()</function> did not print
+ a <literal>~</literal> certainty indicator attached to a segment's
+ upper boundary. Worse, if the lower boundary
+ had <literal>~</literal> while the upper boundary had no indicator,
+ the upper boundary was not printed at all, incorrectly converting
+ the value into an open interval.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master Release: REL_19_BR [9d33a5a80] 2026-06-11 14:29:18 +0900
+Branch: REL_18_STABLE [91b57eade] 2026-06-11 14:29:22 +0900
+Branch: REL_17_STABLE [4a49ab289] 2026-06-11 14:29:24 +0900
+Branch: REL_16_STABLE [18955d412] 2026-06-11 14:29:26 +0900
+Branch: REL_15_STABLE [bc5775149] 2026-06-11 14:29:28 +0900
+Branch: REL_14_STABLE [f3f901a53] 2026-06-11 14:29:29 +0900
+-->
+ <para>
+ Fix crash with namespace nodes in <filename>contrib/xml2</filename>'s
+ <function>xpath_nodeset()</function> function (Andrey Chernyy,
+ Michael Paquier)
+ <ulink url="&commit_baseurl;bc5775149">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: REL_16_STABLE [bc5a873a8] 2026-07-27 10:40:32 -0400
+Branch: REL_15_STABLE [eba7f1dc0] 2026-07-27 10:42:31 -0400
+Branch: REL_14_STABLE [f1c579fc4] 2026-07-27 10:43:14 -0400
+-->
+ <para>
+ Support building <productname>PostgreSQL</productname> with Visual
+ Studio 2026 (Andrew Dunstan)
+ <ulink url="&commit_baseurl;eba7f1dc0">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Daniel Gustafsson <dgustafsson@postgresql.org>
+Branch: master Release: REL_19_BR [89d243d52] 2026-05-29 21:52:35 +0200
+Branch: REL_18_STABLE [27cf3b5af] 2026-06-12 13:57:22 +0200
+Branch: REL_17_STABLE [8bcabfcce] 2026-06-12 13:57:22 +0200
+Branch: REL_16_STABLE [fb8befa7b] 2026-06-12 13:57:22 +0200
+Branch: REL_15_STABLE [c7f70fa1b] 2026-06-12 13:57:22 +0200
+Branch: REL_14_STABLE [086652c02] 2026-06-12 13:57:22 +0200
+-->
+ <para>
+ Support building <productname>PostgreSQL</productname> with
+ OpenSSL 4 (Daniel Gustafsson)
+ <ulink url="&commit_baseurl;c7f70fa1b">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [6ca405938] 2026-08-02 11:26:30 -0400
+Branch: REL_19_STABLE [3c16aa293] 2026-08-02 11:26:30 -0400
+Branch: REL_18_STABLE [5f67124fa] 2026-08-02 11:26:30 -0400
+Branch: REL_17_STABLE [669438aed] 2026-08-02 11:26:30 -0400
+Branch: REL_16_STABLE [796c275a0] 2026-08-02 11:26:30 -0400
+Branch: REL_15_STABLE [af7be5672] 2026-08-02 11:26:30 -0400
+Branch: REL_14_STABLE [812cc1a73] 2026-08-02 11:26:30 -0400
+-->
+ <para>
+ Update time zone data files to <application>tzdata</application>
+ release 2026c (Tom Lane)
+ <ulink url="&commit_baseurl;af7be5672">§</ulink>
+ </para>
+
+ <para>
+ Alberta (America/Edmonton) will be on year-round UTC-06
+ (effectively, permanent DST) beginning in November 2026. This
+ release assumes that their TZ abbreviation will
+ be <literal>CST</literal> from that time forward. That seems likely
+ to change, but it's unclear what new abbreviation will be used.
+ </para>
+
+ <para>
+ Morocco (Africa/Casablanca) will move to permanent UTC+00,
+ without daylight saving time transitions, on 2026-09-20.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </sect2>
+ </sect1>
+
<sect1 id="release-15-18">
<title>Release 15.18</title>
[parent: 7213cbfa0214]