<!-- doc/src/sgml/release-16.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-16-12">
+ <title>Release 16.12</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2026-02-12</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 16.11.
+ For information about new features in major release 16, see
+ <xref linkend="release-16"/>.
+ </para>
+
+ <sect2 id="release-16-12-migration">
+ <title>Migration to Version 16.12</title>
+
+ <para>
+ A dump/restore is not required for those running 16.X.
+ </para>
+
+ <para>
+ However, if you are upgrading from a version earlier than 16.10,
+ see <xref linkend="release-16-10"/>.
+ </para>
+ </sect2>
+
+ <sect2 id="release-16-12-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;1c8c3206f">§</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;e7391bbf1">§</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;fab386f74">§</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;4297a3519">§</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;b497766a8">§</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;a5277700e">§</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;053e1868b">§</ulink>
+ <ulink url="&commit_baseurl;44e8c60be">§</ulink>
+ <ulink url="&commit_baseurl;0e8eaa218">§</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;c1a5bde00">§</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: 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;7efef18ff">§</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;1d7b02711">§</ulink>
+ <ulink url="&commit_baseurl;720e9304f">§</ulink>
+ <ulink url="&commit_baseurl;27e4fad98">§</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: 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;980b7c736">§</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;c7946e6f3">§</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;c48829ed8">§</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;3853f6168">§</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;12c2f843c">§</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;635166913">§</ulink>
+ <ulink url="&commit_baseurl;4d689a176">§</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;4d288e33b">§</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: 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;1aa57e9ed">§</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;0687a6eb0">§</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;75f3428f2">§</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;24cce33c3">§</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;821466722">§</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;e22e9ab0c">§</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;63a65adf4">§</ulink>
+ </para>
+
+ <para>
+ The previous behavior allowed transactions to be lost by a
+ subscriber.
+ </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;a2eeb04f3">§</ulink>
+ </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;821c4d27b">§</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;977a17a3e">§</ulink>
+ <ulink url="&commit_baseurl;e8fd6c9fd">§</ulink>
+ <ulink url="&commit_baseurl;a7bdbbada">§</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;7600dc79c">§</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;600acd34b">§</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;e37b59802">§</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;d62a258cd">§</ulink>
+ <ulink url="&commit_baseurl;0666ccc16">§</ulink>
+ <ulink url="&commit_baseurl;80e8ec772">§</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;7369656fa">§</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;a1407dade">§</ulink>
+ </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;890cc81b6">§</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;e039b09f8">§</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;098a1fab8">§</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;182901626">§</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;f2a6df9fd">§</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;54f82c4aa">§</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;b80227c0a">§</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;d852d105e">§</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-16-11">
<title>Release 16.11</title>
projects / thirdparty / postgresql.git / commitdiff
