<!-- doc/src/sgml/release-17.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-17-8">
+ <title>Release 17.8</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2026-02-12</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 17.7.
+ For information about new features in major release 17, see
+ <xref linkend="release-17"/>.
+ </para>
+
+ <sect2 id="release-17-8-migration">
+ <title>Migration to Version 17.8</title>
+
+ <para>
+ A dump/restore is not required for those running 17.X.
+ </para>
+
+ <para>
+ However, if you are upgrading from a version earlier than 17.6,
+ see <xref linkend="release-17-6"/>.
+ </para>
+ </sect2>
+
+ <sect2 id="release-17-8-changes">
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [35b5c62c3] 2025-11-18 12:56:55 -0500
+Branch: REL_18_STABLE [12bc32917] 2025-11-18 12:56:55 -0500
+Branch: REL_17_STABLE [075a763e2] 2025-11-18 12:56:55 -0500
+Branch: REL_16_STABLE [1c8c3206f] 2025-11-18 12:56:55 -0500
+Branch: REL_15_STABLE [9f5a58aac] 2025-11-18 12:56:55 -0500
+Branch: REL_14_STABLE [b85397481] 2025-11-18 12:56:55 -0500
+-->
+ <para>
+ Don't allow CTE references in sub-selects to determine semantic
+ levels of aggregate functions (Tom Lane)
+ <ulink url="&commit_baseurl;075a763e2">§</ulink>
+ </para>
+
+ <para>
+ This change undoes a change made two minor releases ago, instead
+ throwing an error if a sub-select references a CTE that's below the
+ semantic level that standard SQL rules would assign to the aggregate
+ based on contained column references and aggregates. The attempted
+ fix turned out to cause problems of its own, and it's unclear what
+ to do instead. Since sub-selects within aggregates are disallowed
+ altogether by the SQL standard, treating such cases as errors seems
+ sufficient.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [b4307ae2e] 2026-01-24 11:30:48 +0000
+Branch: REL_18_STABLE [c6ce4dcf9] 2026-01-24 11:30:48 +0000
+Branch: REL_17_STABLE [c5fc17dda] 2026-01-24 11:30:49 +0000
+Branch: REL_16_STABLE [e7391bbf1] 2026-01-24 11:30:50 +0000
+Branch: REL_15_STABLE [c5824536e] 2026-01-24 11:30:51 +0000
+-->
+ <para>
+ Fix trigger transition table capture for <command>MERGE</command>
+ in CTE queries (Dean Rasheed)
+ <ulink url="&commit_baseurl;c5fc17dda">§</ulink>
+ </para>
+
+ <para>
+ When executing a data-modifying CTE query containing both
+ a <command>MERGE</command> and another DML operation on a table with
+ statement-level <literal>AFTER</literal> triggers, the transition
+ tables passed to the triggers would not include the rows affected by
+ the <command>MERGE</command>, only those affected by the other
+ operation(s).
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Langote <amitlan@postgresql.org>
+Branch: master [f9a468c66] 2026-01-23 10:23:30 +0900
+Branch: REL_18_STABLE [9f4b7bfc5] 2026-01-23 10:23:26 +0900
+Branch: REL_17_STABLE [933f67fb6] 2026-01-23 10:23:22 +0900
+Branch: REL_16_STABLE [fab386f74] 2026-01-23 10:23:18 +0900
+Branch: REL_15_STABLE [687533b39] 2026-01-23 10:23:14 +0900
+Branch: REL_14_STABLE [6d2fa44d2] 2026-01-23 10:23:10 +0900
+-->
+ <para>
+ Fix failure when all children of a partitioned target table
+ of an update or delete have been pruned (Amit Langote)
+ <ulink url="&commit_baseurl;933f67fb6">§</ulink>
+ </para>
+
+ <para>
+ In such cases, the executor could report <quote>could not find junk
+ ctid column</quote> errors, even though nothing needs to be done.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [7027dd499] 2026-01-26 23:27:15 +1300
+Branch: REL_18_STABLE [ccde5be68] 2026-01-26 23:46:23 +1300
+Branch: REL_17_STABLE [cae812741] 2026-01-26 23:47:07 +1300
+Branch: REL_16_STABLE [4297a3519] 2026-01-26 23:47:37 +1300
+-->
+ <para>
+ Avoid possible planner failure when a query contains duplicate
+ window function calls (Meng Zhang, David Rowley)
+ <ulink url="&commit_baseurl;cae812741">§</ulink>
+ </para>
+
+ <para>
+ Confusion over de-duplication of such calls could result in errors
+ like <quote>WindowFunc with winref 2 assigned to WindowAgg with
+ winref 1</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [5528e8d10] 2025-11-27 13:09:59 -0500
+Branch: REL_18_STABLE [a212877dc] 2025-11-27 13:09:59 -0500
+Branch: REL_17_STABLE [e79b27662] 2025-11-27 13:09:59 -0500
+Branch: REL_16_STABLE [b497766a8] 2025-11-27 13:09:59 -0500
+Branch: REL_15_STABLE [f19502f04] 2025-11-27 13:09:59 -0500
+Branch: REL_14_STABLE [9e77323fc] 2025-11-27 13:09:59 -0500
+-->
+ <para>
+ Allow indexscans on partial hash indexes even when the index's
+ predicate implies the truth of the WHERE clause (Tom Lane)
+ <ulink url="&commit_baseurl;e79b27662">§</ulink>
+ </para>
+
+ <para>
+ Normally we drop a WHERE clause that is implied by the predicate,
+ since it's pointless to test it; it must hold for every index
+ entry. However that can prevent creation of an indexscan plan if
+ the index is one that requires a WHERE clause on the leading index
+ key, as hash indexes do. Don't drop implied clauses when
+ considering such an index.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [951b60f7a] 2025-12-18 15:08:48 +0200
+Branch: REL_18_STABLE [d77a5f981] 2025-12-18 15:09:26 +0200
+Branch: REL_17_STABLE [4b6d096a0] 2025-12-18 15:09:23 +0200
+Branch: REL_16_STABLE [a5277700e] 2025-12-18 15:09:21 +0200
+Branch: REL_15_STABLE [460d97020] 2025-12-18 15:09:19 +0200
+Branch: REL_14_STABLE [ab4256869] 2025-12-18 15:09:17 +0200
+-->
+ <para>
+ Do not emit WAL for unlogged BRIN indexes (Kirill Reshke)
+ <ulink url="&commit_baseurl;4b6d096a0">§</ulink>
+ </para>
+
+ <para>
+ One seldom-taken code path incorrectly emitted a WAL record
+ relating to a BRIN index even if the index was marked unlogged.
+ Crash recovery would then fail to replay that record, complaining
+ that the file already exists.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [8eeb4a0f7] 2025-11-12 20:59:36 +0200
+Branch: REL_18_STABLE [321ec5462] 2025-11-12 21:00:42 +0200
+Branch: REL_17_STABLE [d02c03ddc] 2025-11-12 21:01:13 +0200
+Branch: REL_16_STABLE [053e1868b] 2025-11-12 21:01:42 +0200
+Branch: REL_15_STABLE [1a469d7b5] 2025-11-12 21:02:12 +0200
+Branch: REL_14_STABLE [eba917d36] 2025-11-12 21:02:36 +0200
+Branch: master [797e9ea6e] 2025-11-12 20:59:44 +0200
+Branch: REL_18_STABLE [7b069a187] 2025-11-12 21:00:46 +0200
+Branch: REL_17_STABLE [c2682810a] 2025-11-12 21:01:16 +0200
+Branch: REL_16_STABLE [44e8c60be] 2025-11-12 21:01:45 +0200
+Branch: REL_15_STABLE [0c862646c] 2025-11-12 21:02:14 +0200
+Branch: REL_14_STABLE [c2e58c071] 2025-11-12 21:02:38 +0200
+Branch: master [0bdc777e8] 2025-11-12 21:19:03 +0200
+Branch: REL_18_STABLE [82fa6b78d] 2025-11-12 21:26:58 +0200
+Branch: REL_17_STABLE [d80d5f099] 2025-11-12 21:27:02 +0200
+Branch: REL_16_STABLE [0e8eaa218] 2025-11-12 21:27:05 +0200
+Branch: REL_15_STABLE [21a9014cf] 2025-11-12 21:27:07 +0200
+Branch: REL_14_STABLE [84f1bf4af] 2025-11-12 21:27:11 +0200
+-->
+ <para>
+ Prevent truncation of CLOG that is still needed by
+ unread <command>NOTIFY</command> messages (Joel Jacobson, Heikki
+ Linnakangas)
+ <ulink url="&commit_baseurl;d02c03ddc">§</ulink>
+ <ulink url="&commit_baseurl;c2682810a">§</ulink>
+ <ulink url="&commit_baseurl;d80d5f099">§</ulink>
+ </para>
+
+ <para>
+ This fix prevents <quote>could not access status of
+ transaction</quote> errors when a backend is slow to
+ absorb <command>NOTIFY</command> messages.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [1b4699090] 2025-11-12 20:59:28 +0200
+Branch: REL_18_STABLE [aab4a84bb] 2025-11-12 21:00:25 +0200
+Branch: REL_17_STABLE [b821c9292] 2025-11-12 21:01:08 +0200
+Branch: REL_16_STABLE [c1a5bde00] 2025-11-12 21:01:39 +0200
+Branch: REL_15_STABLE [b1da37de2] 2025-11-12 21:02:07 +0200
+Branch: REL_14_STABLE [7cb05dd2d] 2025-11-12 21:02:32 +0200
+-->
+ <para>
+ Escalate errors occurring during <command>NOTIFY</command> message
+ processing to FATAL, i.e. close the connection (Heikki Linnakangas)
+ <ulink url="&commit_baseurl;b821c9292">§</ulink>
+ </para>
+
+ <para>
+ Formerly, if a backend got an error while absorbing
+ a <command>NOTIFY</command> message, it would advance past that
+ message, report the error to the client, and move on. That behavior
+ was fraught with problems though. One big concern is that the
+ client has no good way to know that a notification was lost, and
+ certainly no way to know what was in it. Depending on the
+ application logic, missing a notification could cause the
+ application to get stuck waiting, for example. Also, any remaining
+ messages would not get processed until someone sent a
+ new <command>NOTIFY</command>.
+ </para>
+
+ <para>
+ Also, if the connection is idle at the time of receiving
+ a <command>NOTIFY</command> signal, any ERROR would be escalated to
+ FATAL anyway, due to unrelated concerns. Therefore, we've chosen to
+ make that happen in all cases, for consistency and to provide a
+ clear signal to the application that it might have missed some
+ notifications.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [1b92fe7bb] 2025-11-16 22:14:06 +0000
+Branch: REL_18_STABLE [5749d95d4] 2025-11-16 22:15:10 +0000
+Branch: REL_17_STABLE [d6c415c4b] 2025-11-16 22:15:45 +0000
+-->
+ <para>
+ Fix erroneous counting of updates in <command>EXPLAIN ANALYZE
+ MERGE</command> with a concurrent update (Dean Rasheed)
+ <ulink url="&commit_baseurl;d6c415c4b">§</ulink>
+ </para>
+
+ <para>
+ This situation led to an incorrect count of <quote>skipped</quote>
+ tuples in <command>EXPLAIN</command>'s output, or to an assertion
+ failure in an assert-enabled build.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [955f55068] 2025-12-23 13:37:16 +0200
+Branch: REL_18_STABLE [3e3a80f62] 2025-12-23 13:37:23 +0200
+Branch: REL_17_STABLE [bb87d7fef] 2025-12-23 13:37:25 +0200
+Branch: REL_16_STABLE [7efef18ff] 2025-12-23 13:37:27 +0200
+Branch: REL_15_STABLE [5d5487cd2] 2025-12-23 13:37:29 +0200
+Branch: REL_14_STABLE [b6201c76e] 2025-12-23 13:37:31 +0200
+-->
+ <para>
+ Fix bug in following update chain when locking a tuple (Jasper
+ Smit)
+ <ulink url="&commit_baseurl;bb87d7fef">§</ulink>
+ </para>
+
+ <para>
+ This code path neglected to check the xmin of the first new tuple in
+ the update chain, making it possible to lock an unrelated tuple if
+ the original updater aborted and the space was immediately reclaimed
+ by <command>VACUUM</command> and then re-used.
+ That could cause unexpected transaction delays or deadlocks.
+ Errors associated with having identified the wrong tuple have also
+ been observed.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: REL_17_STABLE [0f69bedde] 2025-12-16 16:13:54 -0800
+Branch: REL_16_STABLE [1d7b02711] 2025-12-16 16:13:55 -0800
+Branch: REL_15_STABLE [05d605b6c] 2025-12-16 16:13:55 -0800
+Branch: REL_14_STABLE [811422471] 2025-12-16 16:13:56 -0800
+Branch: REL_17_STABLE [d3e5d8950] 2025-12-16 16:13:54 -0800
+Branch: REL_16_STABLE [720e9304f] 2025-12-16 16:13:55 -0800
+Branch: REL_15_STABLE [20a48c156] 2025-12-16 16:13:55 -0800
+Branch: REL_14_STABLE [e4b1986b9] 2025-12-16 16:13:56 -0800
+Branch: REL_17_STABLE [bcb784e7d] 2025-12-16 16:13:54 -0800
+Branch: REL_16_STABLE [27e4fad98] 2025-12-16 16:13:55 -0800
+Branch: REL_15_STABLE [86091202a] 2025-12-16 16:13:55 -0800
+Branch: REL_14_STABLE [0dfbd191a] 2025-12-16 16:13:56 -0800
+-->
+ <para>
+ Fix issues around in-place catalog updates (Noah Misch)
+ <ulink url="&commit_baseurl;0f69bedde">§</ulink>
+ <ulink url="&commit_baseurl;d3e5d8950">§</ulink>
+ <ulink url="&commit_baseurl;bcb784e7d">§</ulink>
+ </para>
+
+ <para>
+ Send a nontransactional invalidation message for an in-place update,
+ since such an update will survive transaction rollback. Also ensure
+ that the update is WAL-logged before other sessions can see it.
+ These fixes primarily prevent scenarios in which relations'
+ frozen-XID attributes become inconsistent, possibly allowing
+ premature CLOG truncation and subsequent <quote>could not access
+ status of transaction</quote> errors.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Robert Haas <rhaas@postgresql.org>
+Branch: master [ecd275718] 2026-01-19 12:09:32 -0500
+Branch: REL_18_STABLE [c80b0c9d6] 2026-01-19 12:09:48 -0500
+Branch: REL_17_STABLE [ad569b54a] 2026-01-19 12:10:00 -0500
+-->
+ <para>
+ Fix incorrect handling of incremental backups of large tables
+ (Robert Haas, Oleg Tkachenko)
+ <ulink url="&commit_baseurl;ad569b54a">§</ulink>
+ </para>
+
+ <para>
+ If a table exceeding 1GB (or in general, the installation's segment
+ size) is truncated by <literal>VACUUM</literal> between the base
+ backup and the incremental
+ backup, <application>pg_combinebackup</application> could fail with
+ an error about <quote>truncation block length in excess of segment
+ size</quote>. This prevented restoring the incremental backup.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Langote <amitlan@postgresql.org>
+Branch: master [9cbb1d21d] 2026-01-16 13:02:42 +0900
+Branch: REL_18_STABLE [1943ceb38] 2026-01-16 13:14:21 +0900
+Branch: REL_17_STABLE [4071fe900] 2026-01-16 13:19:53 +0900
+Branch: REL_16_STABLE [980b7c736] 2026-01-16 13:19:59 +0900
+Branch: REL_15_STABLE [b926ff137] 2026-01-16 13:20:05 +0900
+Branch: REL_14_STABLE [f6df78173] 2026-01-16 13:20:11 +0900
+-->
+ <para>
+ Fix potential backend process crash at process exit due to trying to
+ release a lock in an already-unmapped shared memory segment
+ (Rahila Syed)
+ <ulink url="&commit_baseurl;4071fe900">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [102bdaa9b] 2026-01-15 16:48:45 +0200
+Branch: REL_18_STABLE [09532a78b] 2026-01-15 16:49:42 +0200
+Branch: REL_17_STABLE [d3ad4cef6] 2026-01-15 16:50:30 +0200
+Branch: REL_16_STABLE [c7946e6f3] 2026-01-15 16:50:37 +0200
+Branch: REL_15_STABLE [a563ac619] 2026-01-15 16:50:42 +0200
+Branch: REL_14_STABLE [46be454ca] 2026-01-15 16:50:46 +0200
+-->
+ <para>
+ Guard against incorrect truncation of the multixact log after a
+ crash (Heikki Linnakangas)
+ <ulink url="&commit_baseurl;d3ad4cef6">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [36b8f4974] 2025-12-27 17:23:30 +0900
+Branch: REL_18_STABLE [06907e864] 2025-12-27 17:23:51 +0900
+Branch: REL_17_STABLE [52b27f585] 2025-12-27 17:23:53 +0900
+Branch: REL_16_STABLE [c48829ed8] 2025-12-27 17:23:54 +0900
+Branch: REL_15_STABLE [300575fe2] 2025-12-27 17:23:56 +0900
+Branch: REL_14_STABLE [ea3524cff] 2025-12-27 17:23:58 +0900
+-->
+ <para>
+ Fix possibly mis-encoded result
+ of <function>pg_stat_get_backend_activity()</function> (Chao Li)
+ <ulink url="&commit_baseurl;52b27f585">§</ulink>
+ </para>
+
+ <para>
+ The shared-memory buffer holding a session's activity string can
+ end with an incomplete multibyte character. Readers are supposed
+ to truncate off any such incomplete character, but this function
+ failed to do so.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [b3ccb0a2c] 2025-12-19 12:05:37 +0900
+Branch: REL_18_STABLE [b863d8d87] 2025-12-19 12:07:10 +0900
+Branch: REL_17_STABLE [699293d27] 2025-12-19 12:07:21 +0900
+Branch: REL_16_STABLE [3853f6168] 2025-12-19 12:08:20 +0900
+Branch: REL_15_STABLE [0fc2f533a] 2025-12-19 12:09:10 +0900
+Branch: REL_14_STABLE [1a9a49699] 2025-12-19 12:09:16 +0900
+-->
+ <para>
+ Guard against recursive memory context logging (Fujii Masao)
+ <ulink url="&commit_baseurl;699293d27">§</ulink>
+ </para>
+
+ <para>
+ A constant flow of signals requesting memory context logging could
+ cause recursive execution of the logging code, which in theory could
+ lead to stack overflow.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Robert Haas <rhaas@postgresql.org>
+Branch: master [f1a6e622b] 2025-12-16 12:24:55 -0500
+Branch: REL_18_STABLE [57df5ab80] 2025-12-16 10:59:05 -0500
+Branch: REL_17_STABLE [1d0fc2499] 2025-12-16 10:59:04 -0500
+Branch: REL_16_STABLE [12c2f843c] 2025-12-16 10:59:02 -0500
+Branch: REL_15_STABLE [bd2726d3e] 2025-12-16 10:59:01 -0500
+Branch: REL_14_STABLE [1d9f7fbba] 2025-12-16 10:59:00 -0500
+-->
+ <para>
+ Fix memory context usage when reinitializing a parallel execution
+ context (Jakub Wartak, Jeevan Chalke)
+ <ulink url="&commit_baseurl;1d0fc2499">§</ulink>
+ </para>
+
+ <para>
+ This error could result in a crash due to a subsidiary data
+ structure having a shorter lifespan than the parallel context.
+ The problem is not known to be reachable using only
+ core <productname>PostgreSQL</productname>, but we have reports of
+ trouble in extensions.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [789d65364] 2025-12-03 19:15:08 +0200
+Branch: REL_18_STABLE [e46041fd9] 2025-12-03 19:15:18 +0200
+Branch: REL_17_STABLE [8ba61bc06] 2025-12-03 19:15:21 +0200
+Branch: REL_16_STABLE [635166913] 2025-12-03 19:15:24 +0200
+Branch: REL_15_STABLE [8cfb174a6] 2025-12-03 19:15:26 +0200
+Branch: REL_14_STABLE [81416e101] 2025-12-03 19:15:29 +0200
+Branch: master [4d936c3ff] 2025-12-05 11:32:38 +0200
+Branch: REL_18_STABLE [02ba5e3be] 2025-12-05 11:35:20 +0200
+Branch: REL_17_STABLE [cad40cec2] 2025-12-05 11:35:44 +0200
+Branch: REL_16_STABLE [4d689a176] 2025-12-05 11:36:36 +0200
+Branch: REL_15_STABLE [b9a02b978] 2025-12-05 11:36:52 +0200
+Branch: REL_14_STABLE [489695554] 2025-12-05 11:37:06 +0200
+-->
+ <para>
+ Set next multixid's offset when creating a new multixid, to remove
+ the wait loop that was needed in corner cases (Andrey Borodin)
+ <ulink url="&commit_baseurl;8ba61bc06">§</ulink>
+ <ulink url="&commit_baseurl;cad40cec2">§</ulink>
+ </para>
+
+ <para>
+ The previous logic could get stuck waiting for an update that would
+ never occur.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Dean Rasheed <dean.a.rasheed@gmail.com>
+Branch: master [3881561d7] 2025-11-29 12:28:59 +0000
+Branch: REL_18_STABLE [b880d9a02] 2025-11-29 12:31:30 +0000
+Branch: REL_17_STABLE [c09096503] 2025-11-29 12:32:12 +0000
+Branch: REL_16_STABLE [4d288e33b] 2025-11-29 12:33:04 +0000
+Branch: REL_15_STABLE [134a8ee22] 2025-11-29 12:33:35 +0000
+Branch: REL_14_STABLE [2d5b97b8c] 2025-11-29 12:34:45 +0000
+-->
+ <para>
+ Avoid rewriting data-modifying CTEs more than once (Bernice Southey,
+ Dean Rasheed)
+ <ulink url="&commit_baseurl;c09096503">§</ulink>
+ </para>
+
+ <para>
+ Formerly, when updating an auto-updatable view or a relation with
+ rules, if the original query had any data-modifying CTEs, the rewriter
+ would rewrite those CTEs multiple times due to recursion. This was
+ inefficient and could produce false errors if a CTE included an
+ update of an always-generated column.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master [dbdc717ac] 2025-11-26 15:12:25 -0600
+Branch: REL_18_STABLE [b83bcc0df] 2025-11-26 15:12:25 -0600
+Branch: REL_17_STABLE [2fc5c5062] 2025-11-26 15:12:25 -0600
+-->
+ <para>
+ Allow retrying initialization of a DSM registry entry
+ (Nathan Bossart)
+ <ulink url="&commit_baseurl;2fc5c5062">§</ulink>
+ </para>
+
+ <para>
+ If we fail partway through initialization of a dynamic shared memory
+ entry, allow the next attempt to use that entry to retry
+ initialization. Previously the entry was left in a
+ permanently-failed state.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [dc7c77f82] 2025-12-16 13:29:28 +0900
+Branch: REL_18_STABLE [68ebdf2b0] 2025-12-16 13:29:36 +0900
+Branch: REL_17_STABLE [f5927da4f] 2025-12-16 13:29:39 +0900
+Branch: REL_16_STABLE [1aa57e9ed] 2025-12-16 13:29:41 +0900
+Branch: REL_15_STABLE [95ef6f490] 2025-12-16 13:29:42 +0900
+Branch: REL_14_STABLE [14161bca4] 2025-12-16 13:29:44 +0900
+-->
+ <para>
+ Fail recovery if WAL does not exist back to the redo point indicated
+ by the checkpoint record (Nitin Jadhav)
+ <ulink url="&commit_baseurl;f5927da4f">§</ulink>
+ </para>
+
+ <para>
+ Add an explicit check for this before starting recovery, so that no
+ harm is done and a useful error message is provided. Previously,
+ recovery might crash or corrupt the database in this situation.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [6ca8506ea] 2026-01-06 17:29:12 +1300
+Branch: REL_18_STABLE [bea57a6b4] 2026-01-06 17:29:44 +1300
+Branch: REL_17_STABLE [bb08ac7ac] 2026-01-06 17:30:08 +1300
+Branch: REL_16_STABLE [0687a6eb0] 2026-01-06 17:30:32 +1300
+Branch: REL_15_STABLE [f20b79059] 2026-01-06 17:30:57 +1300
+Branch: REL_14_STABLE [ae45c7296] 2026-01-06 17:31:20 +1300
+-->
+ <para>
+ Avoid scribbling on the source query tree during <command>ALTER
+ PUBLICATION</command> (Sunil S)
+ <ulink url="&commit_baseurl;bb08ac7ac">§</ulink>
+ </para>
+
+ <para>
+ This error had the visible effect that an event trigger fired for
+ the query would see only the first <literal>publish</literal>
+ option, even if several had been specified. If such a query were
+ set up as a prepared statement, re-executions would misbehave too.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [d926462d8] 2026-01-06 11:52:22 +0900
+Branch: REL_18_STABLE [797fc5d1b] 2026-01-06 11:54:09 +0900
+Branch: REL_17_STABLE [7a990e801] 2026-01-06 11:54:14 +0900
+Branch: REL_16_STABLE [75f3428f2] 2026-01-06 11:54:46 +0900
+Branch: REL_15_STABLE [f7eb44e0f] 2026-01-06 11:55:46 +0900
+-->
+ <para>
+ Pass connection options specified in <literal>CREATE SUBSCRIPTION
+ ... CONNECTION</literal> to the publisher's walsender (Fujii Masao)
+ <ulink url="&commit_baseurl;7a990e801">§</ulink>
+ </para>
+
+ <para>
+ Before this fix, the <literal>options</literal> connection option
+ (if any) was ignored, thus for example preventing setting custom
+ server parameter values in the walsender session. It was intended
+ for that to work, and it did work before refactoring
+ in <productname>PostgreSQL</productname> version 15 broke it, so
+ restore the previous behavior.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [851f6649c] 2026-01-27 05:06:29 +0000
+Branch: REL_18_STABLE [919c9fa13] 2026-01-27 05:45:25 +0000
+Branch: REL_17_STABLE [3243c0177] 2026-01-27 05:49:23 +0000
+Branch: master [3a98f989e] 2026-01-29 03:22:02 +0000
+Branch: REL_18_STABLE [1c60f7236] 2026-01-29 03:34:55 +0000
+Branch: REL_17_STABLE [9649f1adf] 2026-01-29 02:57:02 +0000
+Branch: master [006dd4b2e] 2025-12-08 05:21:22 +0000
+Branch: REL_18_STABLE [d3ceb2084] 2025-12-08 05:33:14 +0000
+Branch: REL_17_STABLE [3510ebeb0] 2026-01-08 07:17:56 +0000
+Branch: REL_16_STABLE [24cce33c3] 2026-01-08 07:07:23 +0000
+Branch: REL_15_STABLE [aae05622a] 2026-01-08 06:54:52 +0000
+Branch: REL_14_STABLE [7406df605] 2026-01-08 06:44:28 +0000
+-->
+ <para>
+ Prevent invalidation of newly created or newly synced replication
+ slots (Zhijie Hou)
+ <ulink url="&commit_baseurl;3243c0177">§</ulink>
+ <ulink url="&commit_baseurl;9649f1adf">§</ulink>
+ <ulink url="&commit_baseurl;3510ebeb0">§</ulink>
+ </para>
+
+ <para>
+ A race condition with a concurrent checkpoint could allow WAL to be
+ removed that is needed by the replication slot, causing the slot to
+ immediately get marked invalid.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Masahiko Sawada <msawada@postgresql.org>
+Branch: master [2a5225b99] 2025-12-30 10:56:30 -0800
+Branch: REL_18_STABLE [fd7c86cfa] 2025-12-30 10:56:28 -0800
+Branch: REL_17_STABLE [123b851ab] 2025-12-30 10:56:25 -0800
+Branch: REL_16_STABLE [821466722] 2025-12-30 10:56:23 -0800
+Branch: REL_15_STABLE [fa557d300] 2025-12-30 10:56:21 -0800
+Branch: REL_14_STABLE [57048d6e1] 2025-12-30 10:56:18 -0800
+-->
+ <para>
+ Fix race condition in computing a replication slot's required xmin
+ (Zhijie Hou)
+ <ulink url="&commit_baseurl;123b851ab">§</ulink>
+ </para>
+
+ <para>
+ This could lead to the error <quote>cannot build an initial slot
+ snapshot as oldest safe xid follows snapshot's xmin</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [8e0d32a4a] 2025-12-23 14:32:14 +0900
+Branch: REL_18_STABLE [b07c32619] 2025-12-23 14:32:19 +0900
+Branch: REL_17_STABLE [e063ccc72] 2025-12-23 14:32:21 +0900
+Branch: REL_16_STABLE [e22e9ab0c] 2025-12-23 14:32:22 +0900
+Branch: REL_15_STABLE [90d1beef6] 2025-12-23 14:32:24 +0900
+Branch: REL_14_STABLE [25a04aa52] 2025-12-23 14:32:25 +0900
+-->
+ <para>
+ During initial synchronization of a logical replication
+ subscription, commit the addition of
+ a <structname>pg_replication_origin</structname> entry before
+ starting to copy data (Zhijie Hou)
+ <ulink url="&commit_baseurl;e063ccc72">§</ulink>
+ </para>
+
+ <para>
+ Previously, if the copy step failed, the
+ new <structname>pg_replication_origin</structname> entry would be
+ lost due to transaction rollback. This led to inconsistent state in
+ shared memory.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [1528b0d89] 2025-12-24 04:36:39 +0000
+Branch: REL_18_STABLE [2f7ffe124] 2025-12-24 04:21:43 +0000
+Branch: REL_17_STABLE [0ed8f1afb] 2025-12-24 04:05:06 +0000
+Branch: REL_16_STABLE [63a65adf4] 2025-12-24 04:19:57 +0000
+-->
+ <para>
+ Don't advance logical replication progress after a parallel worker
+ apply failure (Zhijie Hou)
+ <ulink url="&commit_baseurl;0ed8f1afb">§</ulink>
+ </para>
+
+ <para>
+ The previous behavior allowed transactions to be lost by a
+ subscriber.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Kapila <akapila@postgresql.org>
+Branch: master [04396eacd] 2025-12-09 07:25:20 +0000
+Branch: REL_18_STABLE [6c61c69d5] 2025-12-09 07:12:37 +0000
+Branch: REL_17_STABLE [f2818868a] 2025-12-09 07:02:08 +0000
+-->
+ <para>
+ Fix logical replication slotsync worker processes to handle
+ LOCK_TIMEOUT signals correctly (Zhijie Hou)
+ <ulink url="&commit_baseurl;f2818868a">§</ulink>
+ </para>
+
+ <para>
+ Previously, timeout signals were effectively ignored.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [23b25586d] 2026-01-15 21:02:49 +0200
+Branch: REL_18_STABLE [9ed411e08] 2026-01-15 21:02:54 +0200
+Branch: REL_17_STABLE [c3770181c] 2026-01-15 21:02:59 +0200
+Branch: REL_16_STABLE [a2eeb04f3] 2026-01-15 21:03:12 +0200
+Branch: REL_15_STABLE [ef8465588] 2026-01-15 21:03:16 +0200
+Branch: REL_14_STABLE [2514f1c77] 2026-01-15 20:58:05 +0200
+-->
+ <para>
+ Fix possible failure with <quote>unexpected data beyond EOF</quote>
+ during restart of a streaming replica server (Anthonin Bonnefoy)
+ <ulink url="&commit_baseurl;c3770181c">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Amit Langote <amitlan@postgresql.org>
+Branch: master [519fa0433] 2025-11-27 12:07:01 +0900
+Branch: REL_18_STABLE [15ba0702c] 2025-11-27 11:59:40 +0900
+Branch: REL_17_STABLE [b5511fed5] 2025-11-27 11:59:36 +0900
+-->
+ <para>
+ Fix error reporting for SQL/JSON path type mismatches (Jian He)
+ <ulink url="&commit_baseurl;b5511fed5">§</ulink>
+ </para>
+
+ <para>
+ The code could produce a <quote>cache lookup failed for type 0</quote>
+ error instead of the intended complaint about the path expression
+ not being of the right type.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [349107537] 2026-01-09 11:01:36 +1300
+Branch: REL_18_STABLE [c35e5dd9a] 2026-01-09 11:02:59 +1300
+Branch: REL_17_STABLE [84b787ae6] 2026-01-09 11:03:24 +1300
+Branch: REL_16_STABLE [821c4d27b] 2026-01-09 11:03:48 +1300
+Branch: REL_15_STABLE [3ad05640b] 2026-01-09 11:04:12 +1300
+Branch: REL_14_STABLE [a65995947] 2026-01-09 11:04:39 +1300
+-->
+ <para>
+ Fix erroneous tracking of column position when parsing partition
+ range bounds (myzhen)
+ <ulink url="&commit_baseurl;84b787ae6">§</ulink>
+ </para>
+
+ <para>
+ This could, for example, lead to the wrong column name being cited
+ in error messages about casting partition bound values to the
+ column's data type.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [74a116a79] 2026-02-06 15:38:16 +0900
+Branch: REL_18_STABLE [acfa422c3] 2026-02-06 15:38:21 +0900
+Branch: REL_17_STABLE [67ad4387b] 2026-02-06 15:38:23 +0900
+Branch: REL_16_STABLE [977a17a3e] 2026-02-06 15:38:25 +0900
+Branch: REL_15_STABLE [4ec943f7d] 2026-02-06 15:38:27 +0900
+Branch: REL_14_STABLE [d32e17160] 2026-02-06 15:38:29 +0900
+Branch: master [c8ec74713] 2026-02-04 16:38:06 +0900
+Branch: REL_18_STABLE [2ca4464b6] 2026-02-04 16:38:10 +0900
+Branch: REL_17_STABLE [263af458e] 2026-02-04 16:38:12 +0900
+Branch: master [a9afa021e] 2026-02-02 10:21:04 +0900
+Branch: REL_18_STABLE [ab61f0087] 2026-02-02 10:21:07 +0900
+Branch: REL_17_STABLE [5995135f1] 2026-02-02 10:21:10 +0900
+Branch: master [6bca4b50d] 2026-01-18 17:24:25 +0900
+Branch: REL_18_STABLE [69ee81932] 2026-01-18 17:24:58 +0900
+Branch: REL_17_STABLE [05ef2371a] 2026-01-18 17:25:00 +0900
+Branch: REL_16_STABLE [e8fd6c9fd] 2026-01-18 17:25:01 +0900
+Branch: REL_15_STABLE [fbf8df580] 2026-01-18 17:25:03 +0900
+Branch: REL_14_STABLE [f1dc7a5b7] 2026-01-18 17:25:04 +0900
+Author: Peter Eisentraut <peter@eisentraut.org>
+Branch: master [1653ce523] 2026-02-07 22:37:02 +0100
+Branch: REL_18_STABLE [cff2ef984] 2026-02-07 22:53:16 +0100
+Branch: REL_17_STABLE [5449fd261] 2026-02-07 22:53:21 +0100
+Branch: REL_16_STABLE [a7bdbbada] 2026-02-07 22:53:25 +0100
+Branch: REL_15_STABLE [9dcd0b3de] 2026-02-07 22:53:34 +0100
+Branch: REL_14_STABLE [3e7bb39df] 2026-02-07 22:53:38 +0100
+-->
+ <para>
+ Fix assorted minor errors in error messages (Man Zeng, Tianchen Zhang)
+ <ulink url="&commit_baseurl;67ad4387b">§</ulink>
+ <ulink url="&commit_baseurl;263af458e">§</ulink>
+ <ulink url="&commit_baseurl;5995135f1">§</ulink>
+ <ulink url="&commit_baseurl;05ef2371a">§</ulink>
+ <ulink url="&commit_baseurl;5449fd261">§</ulink>
+ </para>
+
+ <para>
+ For example, an error report about mismatched timeline number in a
+ backup manifest showed the starting timeline number where it meant
+ to show the ending timeline number.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [e5d99b4d9] 2026-01-22 16:03:47 +1300
+Branch: REL_18_STABLE [f1c6b153c] 2026-01-22 16:10:58 +1300
+Branch: REL_17_STABLE [d0bb0e5b3] 2026-01-22 16:10:28 +1300
+Branch: REL_16_STABLE [7600dc79c] 2026-01-22 16:10:08 +1300
+Branch: REL_15_STABLE [cbdd09ae1] 2026-01-22 16:09:29 +1300
+Branch: REL_14_STABLE [de8081c30] 2026-01-22 16:06:06 +1300
+-->
+ <para>
+ Fix failure to perform function inlining when doing JIT compilation
+ with LLVM version 17 or later (Anthonin Bonnefoy)
+ <ulink url="&commit_baseurl;d0bb0e5b3">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [0dceba21d] 2025-11-22 21:21:11 +1300
+Branch: REL_18_STABLE [912cfa314] 2025-11-22 21:21:54 +1300
+Branch: REL_17_STABLE [60215eae7] 2025-11-22 21:22:37 +1300
+Branch: REL_16_STABLE [600acd34b] 2025-11-22 21:23:23 +1300
+Branch: REL_15_STABLE [55164852d] 2025-11-22 21:23:45 +1300
+Branch: REL_14_STABLE [035a1f5ac] 2025-11-22 21:20:27 +1300
+-->
+ <para>
+ Adjust our JIT code to work with LLVM 21 (Holger Hoffstätte)
+ <ulink url="&commit_baseurl;60215eae7">§</ulink>
+ </para>
+
+ <para>
+ The previous coding failed to compile on aarch64 machines.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [f94e9141a] 2026-02-06 17:38:49 +1300
+Branch: REL_18_STABLE [33e3de6d7] 2026-02-06 17:38:39 +1300
+Branch: REL_17_STABLE [4dac22aa1] 2026-02-06 17:41:42 +1300
+Branch: REL_16_STABLE [e37b59802] 2026-02-06 17:43:49 +1300
+-->
+ <para>
+ Add new server parameter <xref linkend="guc-file-extend-method"/> to
+ control use of <function>posix_fallocate()</function> (Thomas Munro)
+ <ulink url="&commit_baseurl;4dac22aa1">§</ulink>
+ </para>
+
+ <para>
+ <productname>PostgreSQL</productname> version 16 and later will
+ use <function>posix_fallocate()</function>, if the platform provides
+ it, to extend relation files. However, this has been reported to
+ interact poorly with some file systems: BTRFS compression is
+ disabled by the use of <function>posix_fallocate()</function>, and
+ XFS could produce spurious <literal>ENOSPC</literal> errors in older
+ Linux kernel versions. To provide a workaround, introduce this new
+ server parameter. Setting <varname>file_extend_method</varname>
+ to <literal>write_zeros</literal> will cause the server to return to
+ the old method of extending files by writing blocks of zeroes.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [c507ba55f] 2025-12-10 09:01:35 +1300
+Branch: REL_18_STABLE [bebb281b0] 2025-12-10 09:05:21 +1300
+Branch: REL_17_STABLE [f24af0e04] 2025-12-10 09:10:31 +1300
+Branch: REL_16_STABLE [d62a258cd] 2025-12-10 09:11:19 +1300
+Branch: master [bec2a0aa3] 2025-12-21 17:34:20 +1300
+Branch: REL_18_STABLE [a7d06e74d] 2025-12-21 17:34:49 +1300
+Branch: REL_17_STABLE [045185913] 2025-12-21 17:35:46 +1300
+Branch: REL_16_STABLE [0666ccc16] 2025-12-21 17:36:04 +1300
+Branch: master [45d92b76d] 2025-12-29 15:47:31 +1300
+Branch: REL_18_STABLE [4da5c33a3] 2025-12-29 15:48:27 +1300
+Branch: REL_17_STABLE [b3c8119e2] 2025-12-29 15:28:17 +1300
+Branch: REL_16_STABLE [80e8ec772] 2025-12-29 15:31:39 +1300
+-->
+ <para>
+ Honor <function>open()</function>'s <literal>O_CLOEXEC</literal>
+ flag on Windows (Bryan Green, Thomas Munro)
+ <ulink url="&commit_baseurl;f24af0e04">§</ulink>
+ <ulink url="&commit_baseurl;045185913">§</ulink>
+ <ulink url="&commit_baseurl;b3c8119e2">§</ulink>
+ </para>
+
+ <para>
+ Make this flag work like it does on POSIX platforms, so that we
+ don't leak file handles into child processes such as <literal>COPY
+ TO/FROM PROGRAM</literal>. While that leakage hasn't caused many
+ problems, it seems undesirable.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [c0bf15729] 2026-02-07 20:05:52 -0500
+Branch: REL_18_STABLE [5eac1d68f] 2026-02-07 20:05:52 -0500
+Branch: REL_17_STABLE [59c2f7efa] 2026-02-07 20:05:52 -0500
+Branch: REL_16_STABLE [7369656fa] 2026-02-07 20:05:52 -0500
+-->
+ <para>
+ Fix failure to parse long options on the server command line in
+ Solaris executables built with meson (Tom Lane)
+ <ulink url="&commit_baseurl;59c2f7efa">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Thomas Munro <tmunro@postgresql.org>
+Branch: master [32b236644] 2025-11-17 12:48:55 +1300
+Branch: REL_18_STABLE [bcfca332f] 2025-11-17 12:48:47 +1300
+Branch: REL_17_STABLE [d66a922f9] 2025-11-17 12:48:37 +1300
+Branch: REL_16_STABLE [a1407dade] 2025-11-17 12:48:22 +1300
+Branch: REL_15_STABLE [3995e4a9d] 2025-11-18 11:19:56 +1300
+Branch: REL_14_STABLE [29a3e22f3] 2025-11-18 11:21:15 +1300
+-->
+ <para>
+ Support process title changes on GNU/Hurd (Michael Banck)
+ <ulink url="&commit_baseurl;d66a922f9">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [d49936f30] 2025-12-18 10:23:47 -0800
+Branch: REL_18_STABLE [573e679a2] 2025-12-18 10:23:51 -0800
+Branch: REL_17_STABLE [1cdc07ad5] 2025-12-18 10:23:51 -0800
+-->
+ <para>
+ Avoid <application>pg_dump</application> assertion failure in
+ binary-upgrade mode (Vignesh C)
+ <ulink url="&commit_baseurl;1cdc07ad5">§</ulink>
+ </para>
+
+ <para>
+ Failure to handle subscription-relation objects in the object
+ sorting code triggered an assertion, though there were no serious
+ ill effects in production builds.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Fujii Masao <fujii@postgresql.org>
+Branch: master [4aa0ac057] 2025-11-14 22:40:39 +0900
+Branch: REL_18_STABLE [00e64e35c] 2025-11-14 22:41:55 +0900
+Branch: REL_17_STABLE [5bc251b28] 2025-11-14 22:42:02 +0900
+-->
+ <para>
+ Fix incorrect error handling in <application>pgbench</application>
+ with multiple <command>\syncpipeline</command> commands
+ in pipeline mode (Yugo Nagata)
+ <ulink url="&commit_baseurl;5bc251b28">§</ulink>
+ </para>
+
+ <para>
+ If multiple <command>\syncpipeline</command> commands are
+ encountered after a query error, <application>pgbench</application>
+ would report <quote>failed to exit pipeline mode</quote>, or get an
+ assertion failure in an assert-enabled build.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [d5b4f3a6d] 2025-11-19 18:05:42 +0200
+Branch: REL_18_STABLE [19594271c] 2025-11-19 18:06:04 +0200
+Branch: REL_17_STABLE [f2e0ca0af] 2025-11-19 18:06:23 +0200
+Branch: REL_16_STABLE [890cc81b6] 2025-11-19 18:06:24 +0200
+Branch: REL_15_STABLE [7c494072b] 2025-11-19 18:06:26 +0200
+Branch: REL_14_STABLE [11cc0f452] 2025-11-19 18:06:27 +0200
+-->
+ <para>
+ Make <application>pg_resetwal</application> print the updated value
+ when changing OldestXID (Heikki Linnakangas)
+ <ulink url="&commit_baseurl;f2e0ca0af">§</ulink>
+ </para>
+
+ <para>
+ It already did that for every other variable it can change.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [94939c5f3] 2025-11-12 12:20:16 +0200
+Branch: REL_18_STABLE [8747b969f] 2025-11-12 12:21:30 +0200
+Branch: REL_17_STABLE [cb2ef0e92] 2025-11-12 12:23:55 +0200
+Branch: REL_16_STABLE [e039b09f8] 2025-11-12 12:45:16 +0200
+Branch: REL_15_STABLE [97cd4b65a] 2025-11-12 12:46:19 +0200
+-->
+ <para>
+ Make <application>pg_resetwal</application> allow setting next
+ multixact xid to 0 or next multixact offset to UINT32_MAX (Maxim
+ Orlov)
+ <ulink url="&commit_baseurl;cb2ef0e92">§</ulink>
+ </para>
+
+ <para>
+ These are valid values, so rejecting them was incorrect. In the
+ worst case, if a pg_upgrade is attempted when exactly at the point
+ of multixact wraparound, the upgrade would fail.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+Branch: master [6bd469d26] 2025-12-04 18:12:08 +0100
+Branch: REL_18_STABLE [df93f94dd] 2025-12-04 18:12:08 +0100
+Branch: REL_17_STABLE [ce2f575b7] 2025-12-04 18:12:08 +0100
+Branch: master [1f28982e4] 2026-01-21 18:55:43 +0100
+Branch: REL_18_STABLE [3c83a2a0a] 2026-01-21 18:55:43 +0100
+Branch: REL_17_STABLE [e1a327dc4] 2026-01-21 18:55:43 +0100
+Branch: REL_16_STABLE [098a1fab8] 2026-01-21 18:55:43 +0100
+Branch: REL_15_STABLE [dcddd6987] 2026-01-21 18:55:43 +0100
+Branch: REL_14_STABLE [607a67c5e] 2026-01-21 18:55:43 +0100
+-->
+ <para>
+ In <filename>contrib/amcheck</filename>, use the correct snapshot
+ for btree index parent checks (Mihail Nikalayeu)
+ <ulink url="&commit_baseurl;ce2f575b7">§</ulink>
+ <ulink url="&commit_baseurl;e1a327dc4">§</ulink>
+ </para>
+
+ <para>
+ The previous coding caused spurious errors when examining indexes
+ created with <command>CREATE INDEX CONCURRENTLY</command>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [cbe04e5d7] 2025-12-02 21:11:15 +0200
+Branch: REL_18_STABLE [19e786727] 2025-12-02 21:15:04 +0200
+Branch: REL_17_STABLE [e8ae59445] 2025-12-02 21:15:28 +0200
+Branch: REL_16_STABLE [182901626] 2025-12-02 21:15:48 +0200
+Branch: REL_15_STABLE [7792bdc45] 2025-12-02 21:16:06 +0200
+Branch: REL_14_STABLE [fbb4b6078] 2025-12-02 21:16:17 +0200
+-->
+ <para>
+ Fix <filename>contrib/amcheck</filename> to
+ handle <quote>half-dead</quote> btree index pages correctly
+ (Heikki Linnakangas)
+ <ulink url="&commit_baseurl;e8ae59445">§</ulink>
+ </para>
+
+ <para>
+ <filename>amcheck</filename> expected such a page to have a parent
+ downlink, but it does not, leading to a false error report
+ about <quote>mismatch between parent key and child high key</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
+Branch: master [6c05ef572] 2025-12-02 21:10:51 +0200
+Branch: REL_18_STABLE [50c63ebb0] 2025-12-02 21:14:53 +0200
+Branch: REL_17_STABLE [5a2d1df00] 2025-12-02 21:15:19 +0200
+Branch: REL_16_STABLE [f2a6df9fd] 2025-12-02 21:15:43 +0200
+Branch: REL_15_STABLE [721b58fbe] 2025-12-02 21:16:01 +0200
+Branch: REL_14_STABLE [a4cb21ea9] 2025-12-02 21:16:13 +0200
+-->
+ <para>
+ Fix <filename>contrib/amcheck</filename> to
+ handle incomplete btree root page splits correctly
+ (Heikki Linnakangas)
+ <ulink url="&commit_baseurl;5a2d1df00">§</ulink>
+ </para>
+
+ <para>
+ <filename>amcheck</filename> could report a false error
+ about <quote>block is not true root</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: David Rowley <drowley@postgresql.org>
+Branch: master [4f49e4b55] 2026-01-04 20:32:40 +1300
+Branch: REL_18_STABLE [07c1c6ec5] 2026-01-04 20:33:14 +1300
+Branch: REL_17_STABLE [a5f2dc421] 2026-01-04 20:33:39 +1300
+Branch: REL_16_STABLE [54f82c4aa] 2026-01-04 20:34:01 +1300
+Branch: REL_15_STABLE [c89510431] 2026-01-04 20:34:22 +1300
+Branch: REL_14_STABLE [67a6fd507] 2026-01-04 20:34:45 +1300
+-->
+ <para>
+ Fix edge-case integer overflow
+ in <filename>contrib/intarray</filename>'s selectivity estimator
+ for <literal>@@</literal> (Chao Li)
+ <ulink url="&commit_baseurl;a5f2dc421">§</ulink>
+ </para>
+
+ <para>
+ This could cause poor selectivity estimates to be produced for cases
+ involving the maximum integer value.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [84d5efa7e] 2025-12-16 10:35:40 -0800
+Branch: REL_18_STABLE [f79e239e0] 2025-12-16 10:36:09 -0800
+Branch: REL_17_STABLE [b8cfe9dc2] 2025-12-16 10:36:29 -0800
+Branch: REL_16_STABLE [b80227c0a] 2025-12-16 10:36:48 -0800
+Branch: REL_15_STABLE [335b2f30b] 2025-12-16 10:37:22 -0800
+Branch: REL_14_STABLE [898991966] 2025-12-16 10:38:15 -0800
+-->
+ <para>
+ Fix multibyte-encoding issue in <filename>contrib/ltree</filename>
+ (Jeff Davis)
+ <ulink url="&commit_baseurl;b8cfe9dc2">§</ulink>
+ </para>
+
+ <para>
+ The previous coding could pass an incomplete multibyte character
+ to <function>lower()</function>, probably resulting in incorrect
+ behavior.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [228fe0c3e] 2026-01-18 14:54:33 -0500
+Branch: REL_18_STABLE [6574bee64] 2026-01-18 14:54:47 -0500
+Branch: REL_17_STABLE [f87c0b84e] 2026-01-18 14:54:54 -0500
+Branch: REL_16_STABLE [d852d105e] 2026-01-18 14:55:01 -0500
+Branch: REL_15_STABLE [00410b76d] 2026-01-18 14:55:07 -0500
+Branch: REL_14_STABLE [8bbf28191] 2026-01-18 14:55:13 -0500
+-->
+ <para>
+ Update time zone data files to <application>tzdata</application>
+ release 2025c (Tom Lane)
+ <ulink url="&commit_baseurl;f87c0b84e">§</ulink>
+ </para>
+
+ <para>
+ The only change is in historical data for pre-1976 timestamps in
+ Baja California.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </sect2>
+ </sect1>
+
<sect1 id="release-17-7">
<title>Release 17.7</title>
projects / thirdparty / postgresql.git / commitdiff
