<!-- doc/src/sgml/release-18.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-18-2">
+ <title>Release 18.2</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2026-02-12</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 18.1.
+ For information about new features in major release 18, see
+ <xref linkend="release-18"/>.
+ </para>
+
+ <sect2 id="release-18-2-migration">
+ <title>Migration to Version 18.2</title>
+
+ <para>
+ A dump/restore is not required for those running 18.X.
+ </para>
+
+ <para>
+ However, if you have any indexes on <type>ltree</type> columns, it may
+ be necessary to reindex them after updating. See the first changelog
+ entry below.
+ </para>
+ </sect2>
+
+ <sect2 id="release-18-2-changes">
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <listitem>
+<!--
+Author: Jeff Davis <jdavis@postgresql.org>
+Branch: master [7f007e4a0] 2025-12-16 12:57:00 -0800
+Branch: REL_18_STABLE [806555e30] 2025-12-16 12:57:12 -0800
+Branch: REL_18_STABLE [8993bf099] 2026-01-27 08:16:07 -0800
+-->
+ <para>
+ Fix inconsistent case-insensitive matching
+ in <filename>contrib/ltree</filename> (Jeff Davis)
+ <ulink url="&commit_baseurl;806555e30">§</ulink>
+ <ulink url="&commit_baseurl;8993bf099">§</ulink>
+ </para>
+
+ <para>
+ Index-related routines in <filename>ltree</filename> used a
+ different implementation of case-folding than the primary operators
+ did. Their behavior was equivalent only if the default collation
+ provider was libc and the encoding was single-byte.
+ </para>
+
+ <para>
+ To fix, change the code to use case-folding with the database's
+ default collation.
+ This change will require reindexing indexes on <type>ltree</type>
+ columns (regardless of the index access method) unless the database
+ uses libc as collation provider and its encoding is single-byte.
+ Without that, searches of such indexes will fail to locate relevant
+ entries.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Álvaro Herrera <alvherre@kurilemu.de>
+Branch: master [96e2af605] 2026-02-03 12:33:29 +0100
+Branch: REL_18_STABLE [492a69e14] 2026-02-03 12:33:29 +0100
+-->
+ <para>
+ When using <command>ALTER TABLE ... ADD CONSTRAINT</command> to add
+ a not-null constraint with an explicit name, if the column is
+ already marked NOT NULL, require that the provided name match the
+ existing constraint name (Álvaro Herrera, Srinath Reddy Sadipiralla)
+ <ulink url="&commit_baseurl;492a69e14">§</ulink>
+ </para>
+ </listitem>
+
+ <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;12bc32917">§</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;c6ce4dcf9">§</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 [889676a0d] 2026-01-16 14:53:50 +0900
+Branch: REL_18_STABLE [f335457e8] 2026-01-16 14:53:32 +0900
+-->
+ <para>
+ Fix incorrect pruning of rowmarks belonging to non-relation
+ rangetable entries, such as subqueries (Dean Rasheed)
+ <ulink url="&commit_baseurl;f335457e8">§</ulink>
+ </para>
+
+ <para>
+ This led to incorrect results if a proposed row update needed to be
+ modified by EvalPlanQual rechecking, as could happen if there was a
+ concurrent update to that row.
+ </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;9f4b7bfc5">§</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: Andres Freund <andres@anarazel.de>
+Branch: master [75609fded] 2026-01-06 19:51:10 -0500
+Branch: REL_18_STABLE [bdc5dedfc] 2026-01-06 19:51:19 -0500
+-->
+ <para>
+ Fix expression evaluation bug for a sub-select within an array
+ subscript (Andres Freund)
+ <ulink url="&commit_baseurl;bdc5dedfc">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [6dfce8420] 2025-12-05 20:10:33 -0500
+Branch: REL_18_STABLE [18b349315] 2025-12-05 20:10:33 -0500
+-->
+ <para>
+ Fix text substring search for non-deterministic collations
+ (Laurenz Albe)
+ <ulink url="&commit_baseurl;18b349315">§</ulink>
+ </para>
+
+ <para>
+ When using a non-deterministic collation, we failed to detect a
+ match occurring at the very end of the searched string.
+ </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;ccde5be68">§</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: Richard Guo <rguo@postgresql.org>
+Branch: master [325808cac] 2025-12-25 12:12:52 +0900
+Branch: REL_18_STABLE [382ce9cb7] 2025-12-25 12:15:09 +0900
+-->
+ <para>
+ Fix planner error with set-returning functions and grouping sets
+ (Richard Guo)
+ <ulink url="&commit_baseurl;382ce9cb7">§</ulink>
+ </para>
+
+ <para>
+ When constructing a ProjectSet plan node, the planner failed to
+ detect that subexpressions involving grouping expressions were
+ already computed by the input plan. This led to inefficient plans
+ or errors such as <quote>variable not found in subplan target
+ list</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [34740b90b] 2026-01-19 11:13:23 +0900
+Branch: REL_18_STABLE [7650eabb6] 2026-01-19 11:14:51 +0900
+-->
+ <para>
+ Avoid incorrect optimization when a subquery's grouping clause
+ contains a volatile or set-returning function (Richard Guo)
+ <ulink url="&commit_baseurl;7650eabb6">§</ulink>
+ </para>
+
+ <para>
+ The planner was willing to push down outer-query restrictions
+ referencing such a grouping column, leading to incorrect behavior
+ due to multiple evaluation of a volatile function, or errors caused
+ by introduction of a set-returning function into the
+ subquery's <literal>WHERE</literal>/<literal>HAVING</literal>
+ clauses.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [559f9e90d] 2025-12-29 11:40:45 +0900
+Branch: REL_18_STABLE [7e9f852a7] 2025-12-29 11:44:14 +0900
+-->
+ <para>
+ Look through PlaceHolderVar nodes when searching for statistics
+ about an expression (Richard Guo)
+ <ulink url="&commit_baseurl;7e9f852a7">§</ulink>
+ </para>
+
+ <para>
+ This change allows the planner to find relevant statistics about
+ expressions pulled up from subqueries or used in <literal>GROUP
+ BY</literal>, avoiding falling back to a default estimate.
+ (Arguably we should adjust any found statistics to account for an
+ increased probability of the value being NULL, but we've never done
+ the equivalent thing for plain Vars either.) While this restriction
+ is old, changes in <productname>PostgreSQL</productname> version 18
+ made PlaceHolderVars more common than before, so make the change to
+ avoid plan regressions in affected cases.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Richard Guo <rguo@postgresql.org>
+Branch: master [ad66f705f] 2025-12-29 11:38:49 +0900
+Branch: REL_18_STABLE [b4cf74420] 2025-12-29 11:43:06 +0900
+-->
+ <para>
+ Look through no-op PlaceHolderVar nodes when matching expressions to
+ indexes (Richard Guo)
+ <ulink url="&commit_baseurl;b4cf74420">§</ulink>
+ </para>
+
+ <para>
+ Because <productname>PostgreSQL</productname> version 18 uses
+ PlaceHolderVars in more cases than before, some queries that
+ formerly could use an index failed to do so. Add logic to prevent
+ that regression.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [ed931377a] 2025-11-17 13:54:52 -0500
+Branch: REL_18_STABLE [bf5b13a8a] 2025-11-17 13:55:26 -0500
+-->
+ <para>
+ Fix planner's conversion of <literal>OR</literal> clauses to
+ ScalarArrayOp index conditions (Tender Wang, Tom Lane)
+ <ulink url="&commit_baseurl;bf5b13a8a">§</ulink>
+ </para>
+
+ <para>
+ The code did not handle RelabelType nodes correctly, and could
+ generate invalid expressions or fail to perform a valid conversion.
+ </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;a212877dc">§</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;d77a5f981">§</ulink>
+ </para>
+
+ <para>
+ One seldom-taken code path unintentionally 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: Tomas Vondra <tomas.vondra@postgresql.org>
+Branch: master [db14dcdec] 2026-01-26 20:05:17 +0100
+Branch: REL_18_STABLE [eee71a66c] 2026-01-26 20:05:00 +0100
+-->
+ <para>
+ Use the correct ordering function in parallel GIN index builds
+ (Tomas Vondra)
+ <ulink url="&commit_baseurl;eee71a66c">§</ulink>
+ </para>
+
+ <para>
+ The parallel code used the default ordering operator (which is
+ determined by the column data type's btree opclass), whereas it
+ should use the ordering function specified by the GIN opclass, if
+ any. This led to a failure if the data type has no btree opclass,
+ or to an invalid index if the opclass specifies an ordering function
+ that doesn't agree with the btree opclass.
+ </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;321ec5462">§</ulink>
+ <ulink url="&commit_baseurl;7b069a187">§</ulink>
+ <ulink url="&commit_baseurl;82fa6b78d">§</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;aab4a84bb">§</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: Michael Paquier <michael@paquier.xyz>
+Branch: master [e217dc748] 2026-01-14 08:44:12 +0900
+Branch: REL_18_STABLE [9c3caad02] 2026-01-14 08:44:52 +0900
+-->
+ <para>
+ Consider grouping expressions when computing a query ID hash
+ (Jian He)
+ <ulink url="&commit_baseurl;9c3caad02">§</ulink>
+ </para>
+
+ <para>
+ Previously, two queries that were the same except in <literal>GROUP
+ BY</literal> expressions would be merged
+ by <filename>contrib/pg_stat_statements</filename> and other users
+ of query IDs.
+ </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;5749d95d4">§</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;3e3a80f62">§</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)
+ </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;c80b0c9d6">§</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;1943ceb38">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Andres Freund <andres@anarazel.de>
+Branch: master [807764990] 2026-01-15 11:09:07 -0500
+Branch: REL_18_STABLE [7f1b3a4ce] 2026-01-15 11:09:49 -0500
+-->
+ <para>
+ Fix race condition in async I/O code (Andres Freund)
+ <ulink url="&commit_baseurl;7f1b3a4ce">§</ulink>
+ </para>
+
+ <para>
+ It was possible for the result code of an asynchronous I/O operation
+ to be overwritten before it was fetched.
+ </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;09532a78b">§</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;06907e864">§</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;b863d8d87">§</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;57df5ab80">§</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;e46041fd9">§</ulink>
+ <ulink url="&commit_baseurl;02ba5e3be">§</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;b880d9a02">§</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;b83bcc0df">§</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: Tomas Vondra <tomas.vondra@postgresql.org>
+Branch: master [3fccbd94c] 2026-01-27 00:21:40 +0100
+Branch: REL_18_STABLE [9796c4f56] 2026-01-26 23:37:03 +0100
+-->
+ <para>
+ Avoid failure of NUMA status views when a page has been swapped out
+ (Tomas Vondra)
+ <ulink url="&commit_baseurl;9796c4f56">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tomas Vondra <tomas.vondra@postgresql.org>
+Branch: master [599336c64] 2025-11-20 13:26:49 +0100
+Branch: REL_18_STABLE [482e98ac4] 2025-11-20 13:26:14 +0100
+-->
+ <para>
+ Avoid <quote>operation not permitted</quote> errors when querying
+ NUMA page status with older libnuma versions (Tomas Vondra)
+ <ulink url="&commit_baseurl;482e98ac4">§</ulink>
+ </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;68ebdf2b0">§</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;bea57a6b4">§</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;797fc5d1b">§</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;919c9fa13">§</ulink>
+ <ulink url="&commit_baseurl;1c60f7236">§</ulink>
+ <ulink url="&commit_baseurl;d3ceb2084">§</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;fd7c86cfa">§</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;b07c32619">§</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;2f7ffe124">§</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;6c61c69d5">§</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;9ed411e08">§</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;15ba0702c">§</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;c35e5dd9a">§</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
+-->
+ <para>
+ Fix assorted minor errors in error messages (Man Zeng, Tianchen Zhang)
+ <ulink url="&commit_baseurl;acfa422c3">§</ulink>
+ <ulink url="&commit_baseurl;2ca4464b6">§</ulink>
+ <ulink url="&commit_baseurl;ab61f0087">§</ulink>
+ <ulink url="&commit_baseurl;69ee81932">§</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;f1c6b153c">§</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;912cfa314">§</ulink>
+ </para>
+
+ <para>
+ The previous coding failed to compile on aarch64 machines.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [6d969ca68] 2025-11-17 15:24:34 -0500
+Branch: REL_18_STABLE [db4eba152] 2025-11-17 15:24:40 -0500
+Branch: master [3e83bdd35] 2025-11-18 16:16:46 -0500
+Branch: REL_18_STABLE [6a5170755] 2025-11-18 16:16:51 -0500
+-->
+ <para>
+ Fix aarch64-specific code to build with old (RHEL7-era) system
+ header files (Tom Lane)
+ <ulink url="&commit_baseurl;db4eba152">§</ulink>
+ <ulink url="&commit_baseurl;6a5170755">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Masahiko Sawada <msawada@postgresql.org>
+Branch: master [85d5bd308] 2025-12-31 11:18:14 -0800
+Branch: REL_18_STABLE [640772c6d] 2025-12-31 11:18:17 -0800
+-->
+ <para>
+ Fix incorrect configure probe
+ for <function>io_uring_queue_init_mem()</function> (Masahiko Sawada)
+ <ulink url="&commit_baseurl;640772c6d">§</ulink>
+ </para>
+
+ <para>
+ This error resulted in failure to optimize async I/O buffer
+ allocations in autotools-based builds, though the code did work when
+ building with meson. The main impact of the omission was
+ slower-than-necessary backend process exits.
+ </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;33e3de6d7">§</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;bebb281b0">§</ulink>
+ <ulink url="&commit_baseurl;a7d06e74d">§</ulink>
+ <ulink url="&commit_baseurl;4da5c33a3">§</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: 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;bcfca332f">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Masahiko Sawada <msawada@postgresql.org>
+Branch: master [c5c808f9b] 2025-12-24 13:55:29 -0800
+Branch: REL_18_STABLE [4e1376900] 2025-12-24 13:55:32 -0800
+-->
+ <para>
+ Fix <application>psql</application>'s tab completion
+ for <command>VACUUM</command> option values (Yugo Nagata)
+ <ulink url="&commit_baseurl;4e1376900">§</ulink>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [4b77282f2] 2026-01-29 16:20:45 +0900
+Branch: REL_18_STABLE [d42735b1e] 2026-01-29 16:20:50 +0900
+-->
+ <para>
+ In <application>psql</application> command prompts,
+ do not show a value for <literal>%P</literal> (pipeline status) when
+ there is no server connection (Chao Li)
+ <ulink url="&commit_baseurl;d42735b1e">§</ulink>
+ </para>
+
+ <para>
+ This makes <literal>%P</literal> act like other prompt escape
+ sequences whose values depend on the active connection.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Nathan Bossart <nathan@postgresql.org>
+Branch: master [7a485bd64] 2026-01-09 10:12:54 -0600
+Branch: REL_18_STABLE [39d555576] 2026-01-09 10:12:54 -0600
+Branch: master [5d1f5079a] 2026-01-11 13:52:50 -0600
+Branch: REL_18_STABLE [56e1f5010] 2026-01-11 13:52:50 -0600
+-->
+ <para>
+ Fix <application>pg_dump</application>'s logic for collecting
+ sequence values (Nathan Bossart)
+ <ulink url="&commit_baseurl;39d555576">§</ulink>
+ <ulink url="&commit_baseurl;56e1f5010">§</ulink>
+ </para>
+
+ <para>
+ <application>pg_dump</application> failed if a sequence was dropped
+ concurrently with the dump, even if the sequence was not among the
+ database objects to be dumped. Also, if the calling user lacks
+ privileges to read a sequence's
+ value, <application>pg_dump</application> emitted incorrect values
+ rather than failing as expected.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Daniel Gustafsson <dgustafsson@postgresql.org>
+Branch: master [ec0da9b89] 2025-12-27 23:05:48 +0100
+Branch: REL_18_STABLE [61c78e1f4] 2025-12-27 23:05:48 +0100
+-->
+ <para>
+ Fix potentially-incorrect quoting
+ of <varname>oauth_validator_libraries</varname> values
+ by <application>pg_dump</application> (ChangAo Chen)
+ <ulink url="&commit_baseurl;61c78e1f4">§</ulink>
+ </para>
+
+ <para>
+ <application>pg_dump</application> applied the wrong quoting rule if
+ it needed to dump a value of this setting.
+ </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;573e679a2">§</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;00e64e35c">§</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;19594271c">§</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;8747b969f">§</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;df93f94dd">§</ulink>
+ <ulink url="&commit_baseurl;3c83a2a0a">§</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;19e786727">§</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;50c63ebb0">§</ulink>
+ </para>
+
+ <para>
+ <filename>amcheck</filename> could report a false error
+ about <quote>block is not true root</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Michael Paquier <michael@paquier.xyz>
+Branch: master [3f83de20b] 2025-12-11 14:11:06 +0900
+Branch: REL_18_STABLE [580b5c2f3] 2025-12-11 14:11:25 +0900
+-->
+ <para>
+ Fix excessive memory allocation
+ in <filename>contrib/pg_buffercache</filename> (David Geier)
+ <ulink url="&commit_baseurl;580b5c2f3">§</ulink>
+ </para>
+
+ <para>
+ The code allocated twice as much memory as it needed for NUMA
+ page status.
+ </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;07c1c6ec5">§</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;f79e239e0">§</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: Michael Paquier <michael@paquier.xyz>
+Branch: master [5d95219fa] 2026-01-20 08:11:12 +0900
+Branch: REL_18_STABLE [3304e97b1] 2026-01-20 08:11:16 +0900
+-->
+ <para>
+ Avoid crash in <filename>contrib/pg_stat_statements</filename> when
+ an <literal>IN</literal> list contains both constants and
+ non-constant expressions (Sami Imseih)
+ <ulink url="&commit_baseurl;3304e97b1">§</ulink>
+ </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;6574bee64">§</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-18-1">
<title>Release 18.1</title>
projects / thirdparty / postgresql.git / commitdiff
