upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-05-28 04:35:45 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Release notes for 18.4, 17.10, 16.14, 15.18, 14.23.

Browse source
This commit is contained in:
Tom Lane 2026-05-10 12:07:32 -04:00
parent fd5b36ab18
commit 80cfa4c2a8
1 changed files with 696 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

696
doc/src/sgml/release-14.sgml
View file

@ -1,6 +1,702 @@
<!-- doc/src/sgml/release-14.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-14-23">
<title>Release 14.23</title>
<formalpara>
<title>Release date:</title>
<para>2026-05-14</para>
</formalpara>
<para>
This release contains a variety of fixes from 14.22.
For information about new features in major release 14, see
<xref linkend="release-14"/>.
</para>
<para>
The <productname>PostgreSQL</productname> community will stop
releasing updates for the 14.X release series in November 2026.
Users are encouraged to update to a newer release branch soon.
</para>
<sect2>
<title>Migration to Version 14.23</title>
<para>
A dump/restore is not required for those running 14.X.
</para>
<para>
However, if you are upgrading from a version earlier than 14.19,
see <xref linkend="release-14-19"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<!--
Author: Richard Guo <rguo@postgresql.org>
Branch: master [f76686ce7] 2026-05-01 11:13:50 +0900
Branch: REL_18_STABLE [e8fd5e579] 2026-05-01 11:16:36 +0900
Branch: master [ba82de48e] 2026-05-08 10:57:50 +0900
Branch: REL_18_STABLE [1132af22c] 2026-05-08 10:59:13 +0900
Branch: master [a1b754558] 2026-05-08 12:45:51 +0900
Branch: REL_18_STABLE [5c214b58b] 2026-05-08 12:47:26 +0900
Branch: master [5a55ea507] 2026-05-05 10:22:53 +0900
Branch: REL_18_STABLE [b62f514ac] 2026-05-05 10:26:17 +0900
Branch: REL_17_STABLE [d0e73bb18] 2026-05-05 10:28:24 +0900
Branch: REL_16_STABLE [748fe9e60] 2026-05-05 10:30:37 +0900
Branch: REL_15_STABLE [872c9fae7] 2026-05-05 10:32:25 +0900
Branch: REL_14_STABLE [8395446df] 2026-05-05 10:33:47 +0900
Branch: master [574581b50] 2026-05-05 10:23:31 +0900
Branch: REL_18_STABLE [bed3ffbf9] 2026-05-05 10:27:06 +0900
Branch: REL_17_STABLE [13226050e] 2026-05-05 10:29:01 +0900
Branch: REL_16_STABLE [5a24cef08] 2026-05-05 10:31:17 +0900
Branch: REL_15_STABLE [bab4f7fa5] 2026-05-05 10:32:42 +0900
Branch: REL_14_STABLE [172034f6e] 2026-05-05 10:34:07 +0900
-->
<para>
Check for nondeterministic collations before assuming that an
equality condition on a collatable type implies uniqueness
(Richard Guo)
<ulink url="&commit_baseurl;8395446df">&sect;</ulink>
<ulink url="&commit_baseurl;172034f6e">&sect;</ulink>
</para>
<para>
Numerous planner optimizations assume that, for example, at most one
table row can satisfy <literal>WHERE x = 'abc'</literal> if there is
a unique index on <literal>x</literal>. However this conclusion is
unsafe in general if the index and the <literal>WHERE</literal>
clause have different collations attached. It is safe when both
collations are deterministic, because that property essentially
requires that equality of two strings means bitwise equality. But
nondeterministic collations don't act that way, so that optimizing
on the assumption of unique matches can give wrong query answers if
either the <literal>WHERE</literal> clause or the index has a
nondeterministic collation.
</para>
</listitem>
<listitem>
<!--
Author: Richard Guo <rguo@postgresql.org>
Branch: master [c6a79be3f] 2026-04-21 14:28:26 +0900
Branch: REL_18_STABLE [e528bfe97] 2026-04-21 14:29:33 +0900
Branch: REL_17_STABLE [9d6208939] 2026-04-21 14:31:15 +0900
Branch: REL_16_STABLE [07b257189] 2026-04-21 14:33:07 +0900
Branch: REL_15_STABLE [7062bd577] 2026-04-21 14:33:57 +0900
Branch: REL_14_STABLE [8e39951be] 2026-04-21 14:35:43 +0900
-->
<para>
Fix incorrect handling of <literal>NEW</literal> generated columns
in rule actions and rule qualifications (Richard Guo, Dean Rasheed)
<ulink url="&commit_baseurl;8e39951be">&sect;</ulink>
</para>
<para>
Previously, such column references would produce NULL
in <literal>INSERT</literal> cases, or be equivalent to
the <literal>OLD</literal> value in <literal>UPDATE</literal> cases.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_18_STABLE [11c2c0cc8] 2026-04-06 14:22:17 -0400
Branch: REL_17_STABLE [681a91d29] 2026-04-06 14:22:17 -0400
Branch: REL_16_STABLE [3c7a6bbe6] 2026-04-06 14:22:17 -0400
Branch: REL_15_STABLE [07e833e3c] 2026-04-06 14:22:17 -0400
Branch: REL_14_STABLE [40fa04e7c] 2026-04-06 14:22:17 -0400
-->
<para>
Fix spurious <quote>generated columns are not supported in COPY FROM
WHERE conditions</quote> errors (Tom Lane)
<ulink url="&commit_baseurl;40fa04e7c">&sect;</ulink>
</para>
<para>
Use of a system column in a <literal>COPY FROM WHERE</literal>
condition could sometimes incorrectly report this error.
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [6cf49e804] 2026-04-30 11:04:57 -0400
Branch: REL_18_STABLE [149c875fc] 2026-04-30 11:05:29 -0400
Branch: REL_17_STABLE [a0104b447] 2026-04-30 11:14:37 -0400
Branch: REL_16_STABLE [7bb519635] 2026-04-30 11:14:26 -0400
Branch: REL_15_STABLE [76d15a7ee] 2026-04-30 11:14:12 -0400
Branch: REL_14_STABLE [81b56b47c] 2026-04-30 11:13:50 -0400
-->
<para>
Fix <literal>CREATE TABLE ... LIKE ... INCLUDING
STATISTICS</literal> for cases where the source table has dropped
column(s) (Julien Tachoires)
<ulink url="&commit_baseurl;81b56b47c">&sect;</ulink>
</para>
<para>
In such cases, extended statistics objects could be copied
incorrectly, or the command could give an incorrect error.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [9d3e094f1] 2026-04-22 10:32:10 +0900
Branch: REL_18_STABLE [5713ac248] 2026-04-22 10:34:33 +0900
Branch: REL_17_STABLE [becf6d269] 2026-04-22 10:34:35 +0900
Branch: REL_16_STABLE [313355d68] 2026-04-22 10:34:37 +0900
Branch: REL_15_STABLE [0859000d0] 2026-04-22 10:34:38 +0900
Branch: REL_14_STABLE [d809b16d1] 2026-04-22 10:34:40 +0900
-->
<para>
Allow <literal>ALTER INDEX ... ATTACH PARTITION</literal> to mark
the parent index valid if appropriate (Sami Imseih)
<ulink url="&commit_baseurl;d809b16d1">&sect;</ulink>
</para>
<para>
There are edge cases in which a partitioned index might remain
marked as invalid even when all its leaf indexes are valid. This
change provides a mechanism whereby a user can correct such a
situation without resorting to manual catalog updates.
</para>
</listitem>
<listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [703fee3b2] 2026-03-19 15:07:43 -0700
Branch: REL_18_STABLE [c11f87b1a] 2026-03-19 14:59:30 -0700
Branch: REL_17_STABLE [876fa84a2] 2026-03-19 15:02:18 -0700
Branch: REL_16_STABLE [a19edb66a] 2026-03-19 15:00:58 -0700
Branch: REL_15_STABLE [3a35ab1d0] 2026-03-19 15:01:22 -0700
Branch: REL_14_STABLE [c6f369e58] 2026-03-19 15:01:45 -0700
-->
<para>
Fix <command>ALTER FOREIGN DATA WRAPPER</command> to not drop the
wrapper object's dependency on its handler function (Jeff Davis)
<ulink url="&commit_baseurl;c6f369e58">&sect;</ulink>
</para>
</listitem>
<listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [dd4069197] 2026-04-23 21:28:11 +0300
Branch: REL_18_STABLE [ff8f27d6e] 2026-04-23 21:28:59 +0300
Branch: REL_17_STABLE [54343f6f9] 2026-04-23 21:31:32 +0300
Branch: REL_16_STABLE [06e304524] 2026-04-23 21:33:02 +0300
Branch: REL_15_STABLE [34ebeb15c] 2026-04-23 21:33:25 +0300
Branch: REL_14_STABLE [c7a1d5fc6] 2026-04-23 21:33:39 +0300
-->
<para>
Disallow making a composite type be a member of itself via a
multirange (Heikki Linnakangas)
<ulink url="&commit_baseurl;c7a1d5fc6">&sect;</ulink>
</para>
<para>
We already forbade such cases when the intermediate type is a
domain, array, composite type, or range; but multiranges were
overlooked.
</para>
</listitem>
<listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [0d866282b] 2026-03-30 16:14:34 +1300
Branch: REL_18_STABLE [49315de0c] 2026-03-30 16:16:09 +1300
Branch: REL_17_STABLE [d29808e35] 2026-03-30 16:16:39 +1300
Branch: REL_16_STABLE [1bd90c887] 2026-03-30 16:17:14 +1300
Branch: REL_15_STABLE [6b2e091f0] 2026-03-30 16:17:39 +1300
Branch: REL_14_STABLE [6ce5c310b] 2026-03-30 16:18:13 +1300
-->
<para>
Fix datum-image comparisons to be insensitive to sign-extension
variations (David Rowley)
<ulink url="&commit_baseurl;6ce5c310b">&sect;</ulink>
</para>
<para>
This fixes some situations that previously led to <quote>could not
find memoization table entry</quote> errors or wrong query results.
</para>
</listitem>
<listitem>
<!--
Author: David Rowley <drowley@postgresql.org>
Branch: master [94219a73f] 2026-04-24 14:03:12 +1200
Branch: REL_18_STABLE [035c520db] 2026-04-24 14:03:41 +1200
Branch: REL_17_STABLE [3fda3e12f] 2026-04-24 14:04:05 +1200
Branch: REL_16_STABLE [a2a0060d5] 2026-04-24 14:04:31 +1200
Branch: REL_15_STABLE [622f8b530] 2026-04-24 14:04:55 +1200
Branch: REL_14_STABLE [109de35b7] 2026-04-24 14:05:23 +1200
-->
<para>
Fix incorrect logic for hashed <literal>IN</literal>/<literal>NOT
IN</literal> with non-strict equality operator (Chengpeng Yan)
<ulink url="&commit_baseurl;109de35b7">&sect;</ulink>
</para>
<para>
The previous coding could crash or give wrong answers. All built-in
data types have strict equality operators, so that this issue could
only arise with an extension data type.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [a50777680] 2026-04-22 12:41:00 -0400
Branch: REL_18_STABLE [580e7be88] 2026-04-22 12:41:00 -0400
Branch: REL_17_STABLE [c97a28618] 2026-04-22 12:41:00 -0400
Branch: REL_16_STABLE [e1e60f148] 2026-04-22 12:41:01 -0400
Branch: REL_15_STABLE [f60d25986] 2026-04-22 12:41:01 -0400
Branch: REL_14_STABLE [8a6f08c0c] 2026-04-22 12:41:01 -0400
-->
<para>
Truncate overly-long locale-specific numeric symbols
in <function>to_char()</function> (Tom Lane)
<ulink url="&commit_baseurl;8a6f08c0c">&sect;</ulink>
</para>
<para>
If a locale specified a currency symbol, thousands separator, or
decimal or sign symbol more than 8 bytes long, a buffer overrun was
possible. No such locales exist in the real world, and it's
impractical for an unprivileged attacker to install a malicious
locale definition underneath a Postgres server; but for safety's
sake check for overlength symbols and truncate if needed.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [d7970e7e9] 2026-04-22 12:02:15 -0400
Branch: REL_18_STABLE [00c6e0819] 2026-04-22 12:02:15 -0400
Branch: REL_17_STABLE [ea5f0d176] 2026-04-22 12:02:15 -0400
Branch: REL_16_STABLE [42383d32d] 2026-04-22 12:02:15 -0400
Branch: REL_15_STABLE [0b196d3db] 2026-04-22 12:02:15 -0400
Branch: REL_14_STABLE [21a24d709] 2026-04-22 12:02:15 -0400
Branch: master [844bb90d4] 2026-04-22 10:47:56 -0400
Branch: REL_18_STABLE [c2bfeb3bb] 2026-04-22 11:04:35 -0400
Branch: REL_17_STABLE [a5426dbf8] 2026-04-22 11:05:51 -0400
Branch: REL_16_STABLE [17f72e037] 2026-04-22 11:06:47 -0400
Branch: REL_15_STABLE [f852c9093] 2026-04-22 11:09:02 -0400
Branch: REL_14_STABLE [6cae0c2bd] 2026-04-22 11:09:21 -0400
-->
<para>
Prevent buffer overruns when parsing an affix file for
an <literal>Ispell</literal> dictionary (Tom Lane)
<ulink url="&commit_baseurl;21a24d709">&sect;</ulink>
<ulink url="&commit_baseurl;6cae0c2bd">&sect;</ulink>
</para>
<para>
A corrupt or malicious affix file could crash the server.
This is not considered a security issue because text search
configuration files are presumed trustworthy, but it still seems
worth fixing.
</para>
</listitem>
<listitem>
<!--
Author: Richard Guo <rguo@postgresql.org>
Branch: master [8b6c89e37] 2026-04-09 19:28:33 +0900
Branch: REL_18_STABLE [bfc7dff26] 2026-04-09 19:30:37 +0900
Branch: REL_17_STABLE [f8736f8bc] 2026-04-09 19:32:09 +0900
Branch: REL_16_STABLE [0fe032e6a] 2026-04-09 19:34:02 +0900
Branch: REL_15_STABLE [4da71fc37] 2026-04-09 19:35:08 +0900
Branch: REL_14_STABLE [305cf0df0] 2026-04-09 19:36:13 +0900
-->
<para>
Guard against integer overflow in calculations of frame start and
end positions for window aggregates (Richard Guo)
<ulink url="&commit_baseurl;305cf0df0">&sect;</ulink>
</para>
<para>
Very large user-specified offsets (close to INT64_MAX) could result
in errors or incorrect query results.
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [2b5ba2a0a] 2026-04-10 07:13:08 -0400
Branch: REL_18_STABLE [c3e436b1c] 2026-04-10 10:28:00 -0400
Branch: REL_17_STABLE [c05c3baf1] 2026-04-10 10:27:43 -0400
Branch: REL_16_STABLE [e630f65d0] 2026-04-10 10:27:16 -0400
Branch: REL_15_STABLE [c88ad3a21] 2026-04-10 10:26:50 -0400
Branch: REL_14_STABLE [de32a01e7] 2026-04-10 10:22:48 -0400
-->
<para>
Fix buffer overread when <function>pglz_decompress()</function>
receives corrupt input (Andrew Dunstan)
<ulink url="&commit_baseurl;de32a01e7">&sect;</ulink>
</para>
<para>
It was possible to read a few bytes past the end of the input, which
in very unlucky cases might cause a crash.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [739477345] 2026-03-30 13:59:58 -0400
Branch: REL_18_STABLE [adb7873bb] 2026-03-30 13:59:54 -0400
Branch: REL_17_STABLE [1f5b6a5e5] 2026-03-30 13:59:54 -0400
Branch: REL_16_STABLE [59c139d53] 2026-03-30 13:59:54 -0400
Branch: REL_15_STABLE [811f3263a] 2026-03-30 13:59:54 -0400
Branch: REL_14_STABLE [7cd23aad2] 2026-03-30 13:59:54 -0400
-->
<para>
Ensure that tuplestore data structures are internally consistent
even after an error (Tom Lane)
<ulink url="&commit_baseurl;7cd23aad2">&sect;</ulink>
</para>
<para>
The code was previously careless about this, which is fine most of
the time but is problematic for the tuplestore backing
a <literal>WITH HOLD</literal> cursor. In v15 and before this
leads to easily-reproducible crashes; later branches are not known
to be vulnerable, but it seems best to preserve consistency in all.
</para>
</listitem>
<listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [eef1ba704] 2026-03-26 20:49:31 +0900
Branch: REL_18_STABLE [98e96e579] 2026-03-26 20:50:22 +0900
Branch: REL_17_STABLE [fdce5de55] 2026-03-26 20:50:27 +0900
Branch: REL_16_STABLE [f42105001] 2026-03-26 20:50:33 +0900
Branch: REL_15_STABLE [246c296f0] 2026-03-26 20:50:38 +0900
Branch: REL_14_STABLE [bf7ecf353] 2026-03-26 20:50:43 +0900
-->
<para>
Fix premature NULL lag reporting
in <structname>pg_stat_replication</structname> (Shinya Kato)
<ulink url="&commit_baseurl;bf7ecf353">&sect;</ulink>
</para>
<para>
The lag columns frequently read as NULL even while replication
activity was happening.
</para>
</listitem>
<listitem>
<!--
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Branch: master [b1f14c967] 2026-03-13 23:25:24 +0100
Branch: REL_18_STABLE [5b3f63a1b] 2026-03-13 23:26:02 +0100
Branch: REL_17_STABLE [6ef36bb35] 2026-03-13 23:26:15 +0100
Branch: REL_16_STABLE [4f4025eac] 2026-03-13 23:26:25 +0100
Branch: REL_15_STABLE [ce06b5740] 2026-03-13 23:26:36 +0100
Branch: REL_14_STABLE [c0ffc725f] 2026-03-13 23:26:49 +0100
-->
<para>
Avoid rare flush failure when working with non-WAL-logged GiST
indexes (Tomas Vondra)
<ulink url="&commit_baseurl;c0ffc725f">&sect;</ulink>
</para>
<para>
A non-logged GiST index could nonetheless sometimes
produce <quote>xlog flush request <replaceable>n/nnnn</replaceable>
is not satisfied</quote> errors, due to incorrect selection of
a <quote>fake LSN</quote> to represent an insertion point.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [4da2afd01] 2026-03-09 13:46:27 +0900
Branch: REL_18_STABLE [a0f38604d] 2026-03-09 13:46:31 +0900
Branch: REL_17_STABLE [2543b9ea9] 2026-03-09 13:46:33 +0900
Branch: REL_16_STABLE [0af5e64e9] 2026-03-09 13:46:35 +0900
Branch: REL_15_STABLE [46c93b705] 2026-03-09 13:46:37 +0900
Branch: REL_14_STABLE [eb11d7a91] 2026-03-09 13:46:38 +0900
-->
<para>
Fix underestimate of required size of DSA page maps for odd-size
segments (Paul Bunn)
<ulink url="&commit_baseurl;eb11d7a91">&sect;</ulink>
</para>
<para>
This miscalculation led to out-of-bounds accesses and hence server
crashes.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [3b7a6fa15] 2026-03-02 09:38:37 +0900
Branch: REL_18_STABLE [83671c0da] 2026-03-02 09:38:40 +0900
Branch: REL_17_STABLE [530b6b02f] 2026-03-02 09:38:42 +0900
Branch: REL_16_STABLE [04745ba9c] 2026-03-02 09:38:44 +0900
Branch: REL_15_STABLE [f033abc6c] 2026-03-02 09:38:46 +0900
Branch: REL_14_STABLE [038c7d4a3] 2026-03-02 09:38:47 +0900
-->
<para>
Fix possible server crash when processing extended statistics on
expressions of extension data types (Michael Paquier)
<ulink url="&commit_baseurl;038c7d4a3">&sect;</ulink>
</para>
<para>
NULL pointer dereferences were possible if the data type's
typanalyze function does not compute any useful statistics.
No in-core typanalyze function behaves that way, but extensions
could.
</para>
</listitem>
<listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: REL_18_STABLE [0852643e1] 2026-03-23 11:53:32 +0200
Branch: REL_17_STABLE [1ca385032] 2026-03-23 11:59:07 +0200
Branch: REL_16_STABLE [77dff5d93] 2026-03-23 12:02:27 +0200
Branch: REL_15_STABLE [a5f412107] 2026-03-23 12:02:35 +0200
Branch: REL_14_STABLE [e35e466f6] 2026-03-23 12:03:30 +0200
-->
<para>
Fix race condition between WAL replay of checkpoints and multixact
ID creations (Heikki Linnakangas)
<ulink url="&commit_baseurl;e35e466f6">&sect;</ulink>
</para>
<para>
A standby server following WAL from a primary of an older minor
version could get into a crash-and-restart loop complaining
about <quote>could not access status of transaction</quote>.
</para>
</listitem>
<listitem>
<!--
Author: Fujii Masao <fujii@postgresql.org>
Branch: master [6eedb2a5f] 2026-03-06 16:43:40 +0900
Branch: REL_18_STABLE [3eb2fecdb] 2026-03-06 16:44:40 +0900
Branch: REL_17_STABLE [bbbc0888b] 2026-03-06 16:44:45 +0900
Branch: REL_16_STABLE [82935467a] 2026-03-06 16:44:51 +0900
Branch: REL_15_STABLE [42734f296] 2026-03-06 16:44:59 +0900
Branch: REL_14_STABLE [3bf6f22ce] 2026-03-06 16:45:05 +0900
Branch: master [d927b4bd9] 2026-03-17 08:10:20 +0900
Branch: REL_18_STABLE [980498138] 2026-03-17 08:12:25 +0900
Branch: REL_17_STABLE [8ee536c89] 2026-03-17 08:12:32 +0900
Branch: REL_16_STABLE [da21ecf57] 2026-03-17 08:12:37 +0900
Branch: REL_15_STABLE [fa9f2e317] 2026-03-17 08:12:41 +0900
Branch: REL_14_STABLE [f15471464] 2026-03-17 08:12:46 +0900
-->
<para>
Prevent indefinite wait in shutdown of a walsender process
(Anthonin Bonnefoy)
<ulink url="&commit_baseurl;3bf6f22ce">&sect;</ulink>
<ulink url="&commit_baseurl;f15471464">&sect;</ulink>
</para>
<para>
At shutdown of a cluster that is publishing logical replication
data, the walsender waits for all pending WAL to be written out.
But it did not correctly request that to happen, so that in some
cases this could become an indefinite wait.
</para>
</listitem>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [c06d1a4ba] 2026-05-03 20:23:50 +0300
Branch: REL_18_STABLE [ac3b97db3] 2026-05-03 20:27:36 +0300
Branch: REL_17_STABLE [1cf010f21] 2026-05-03 20:27:33 +0300
Branch: REL_16_STABLE [54537de35] 2026-05-03 20:27:02 +0300
Branch: REL_15_STABLE [ca259b084] 2026-05-03 20:26:55 +0300
Branch: REL_14_STABLE [f5d1038d9] 2026-05-03 20:26:07 +0300
-->
<para>
Ensure that changes to tables' free space maps are persisted during
recovery (Alexey Makhmutov)
<ulink url="&commit_baseurl;f5d1038d9">&sect;</ulink>
</para>
<para>
Previously, while WAL replay did update the free space map while
replaying operations that should change it, the map page buffer did
not get marked dirty if checksums are enabled, so that the changes
might never get written out. On a standby server, over time this
would result in a map wildly at variance with the table's actual
contents. While the map is only used as a hint, this condition
could cause significant performance degradation for some period of
time after the standby server is promoted to be active, until most
of the map has been repaired by updates.
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [c34a280c8] 2026-05-01 15:12:28 -0400
Branch: REL_18_STABLE [e2688ea5e] 2026-05-01 15:15:15 -0400
Branch: REL_17_STABLE [5d67549d9] 2026-05-01 15:15:23 -0400
Branch: REL_16_STABLE [7e4c871f4] 2026-05-01 15:15:33 -0400
Branch: REL_15_STABLE [6916f4410] 2026-05-01 15:16:02 -0400
Branch: REL_14_STABLE [f0e3f9732] 2026-05-01 15:16:42 -0400
-->
<para>
Fix crashes in some <application>ecpg</application> functions when
called without any established connection (Shruthi Gowda)
<ulink url="&commit_baseurl;f0e3f9732">&sect;</ulink>
</para>
</listitem>
<listitem>
<!--
Author: Jacob Champion <jchampion@postgresql.org>
Branch: master [a60a10338] 2026-02-24 14:01:37 -0800
Branch: REL_18_STABLE [1b2773179] 2026-02-24 14:01:41 -0800
Branch: REL_17_STABLE [ad7fc3f1f] 2026-02-24 14:01:46 -0800
Branch: REL_16_STABLE [a38ed212f] 2026-02-24 14:01:51 -0800
Branch: REL_15_STABLE [e726620d2] 2026-02-24 14:01:54 -0800
Branch: REL_14_STABLE [c47744ede] 2026-02-24 14:01:58 -0800
-->
<para>
In <application>pg_upgrade</application>, take care to use the
correct protocol version when connecting to older source servers
(Jacob Champion)
<ulink url="&commit_baseurl;c47744ede">&sect;</ulink>
</para>
<para>
This could be problematic when attempting to upgrade from a pre-2018
server.
</para>
</listitem>
<listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [c8308a984] 2026-02-26 12:23:22 -0800
Branch: REL_18_STABLE [b3c2a3d38] 2026-02-26 12:23:51 -0800
Branch: REL_18_STABLE [53a57cae1] 2026-02-26 15:19:31 -0800
Branch: REL_17_STABLE [d1bd9a7dc] 2026-02-26 12:24:12 -0800
Branch: REL_16_STABLE [3ed2c7ef7] 2026-02-26 12:25:00 -0800
Branch: REL_15_STABLE [2b993167f] 2026-02-26 12:26:13 -0800
Branch: REL_14_STABLE [058710d41] 2026-02-26 12:26:32 -0800
-->
<para>
Fix <filename>contrib/ltree</filename> to cope when case-folding
changes a string's byte length (Jeff Davis)
<ulink url="&commit_baseurl;058710d41">&sect;</ulink>
</para>
<para>
Previously, <type>lquery</type> patterns specifying case-insensitive
matching might fail to match labels they should match.
</para>
</listitem>
<listitem>
<!--
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [3c74cb576] 2026-03-27 12:25:10 +0200
Branch: REL_18_STABLE [25b02320e] 2026-03-27 12:21:29 +0200
Branch: REL_17_STABLE [351e59f34] 2026-03-27 12:21:38 +0200
Branch: REL_16_STABLE [52edaf9d9] 2026-03-27 12:21:48 +0200
Branch: REL_15_STABLE [92cf11171] 2026-03-27 12:22:21 +0200
Branch: REL_14_STABLE [a6d03067f] 2026-03-27 12:23:38 +0200
-->
<para>
In <filename>contrib/pg_stat_statements</filename>, don't leak
memory if an error occurs while parsing the
<filename>pgss_query_texts.stat</filename> file (Heikki Linnakangas)
<ulink url="&commit_baseurl;a6d03067f">&sect;</ulink>
</para>
</listitem>
<listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [648818ba3] 2026-05-05 18:55:00 +0900
Branch: REL_18_STABLE [c318777da] 2026-05-05 18:55:02 +0900
Branch: REL_17_STABLE [af8f9248f] 2026-05-05 18:55:03 +0900
Branch: REL_16_STABLE [1352651c2] 2026-05-05 18:55:04 +0900
Branch: REL_15_STABLE [34c18a225] 2026-05-05 18:55:05 +0900
Branch: REL_14_STABLE [fd5b36ab1] 2026-05-05 18:55:06 +0900
-->
<para>
In <filename>contrib/postgres_fdw</filename>, avoid crash due to
premature cleanup of a failed connection (Etsuro Fujita)
<ulink url="&commit_baseurl;fd5b36ab1">&sect;</ulink>
</para>
<para>
If a remote connection fails abort cleanup, we can't use it any
longer. But delay closing the connection object until end of
transaction, because there might still be references to it within
data structures such as open cursors.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f64f62f5b] 2026-04-24 12:28:35 -0400
Branch: REL_18_STABLE [8a431b6d6] 2026-04-24 12:28:35 -0400
Branch: REL_17_STABLE [4c0eab6f0] 2026-04-24 12:28:35 -0400
Branch: REL_16_STABLE [0465c999e] 2026-04-24 12:28:35 -0400
Branch: REL_15_STABLE [e28fc73d5] 2026-04-24 12:28:35 -0400
Branch: REL_14_STABLE [affd929c9] 2026-04-24 12:28:35 -0400
-->
<para>
Update time zone data files to <application>tzdata</application>
release 2026b (Tom Lane)
<ulink url="&commit_baseurl;affd929c9">&sect;</ulink>
</para>
<para>
British Columbia (America/Vancouver) will be on year-round UTC-07
(effectively, permanent DST) beginning in November 2026. This
release assumes that their TZ abbreviation will
be <literal>MST</literal> from that time forward. That seems likely
to change, but it's unclear what new abbreviation will be used.
Also a historical correction for Moldova: they have followed EU DST
transition times since 2022.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-14-22">
<title>Release 14.22</title>