From ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164 Mon Sep 17 00:00:00 2001 From: Tom Lane <tgl@sss.pgh.pa.us> Date: Fri, 2 Aug 2024 16:24:17 -0400 Subject: [PATCH] First-draft release notes for 16.4. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. --- doc/src/sgml/release-16.sgml | 1239 ++++++++++++++++++++++++++++++++++ 1 file changed, 1239 insertions(+) diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml index 54860aa0e1d..69eee35eedc 100644 --- a/doc/src/sgml/release-16.sgml +++ b/doc/src/sgml/release-16.sgml @@ -1,6 +1,1245 @@ <!-- doc/src/sgml/release-16.sgml --> <!-- See header comment in release.sgml about typical markup --> + <sect1 id="release-16-4"> + <title>Release 16.4</title> + + <formalpara> + <title>Release date:</title> + <para>2024-08-08</para> + </formalpara> + + <para> + This release contains a variety of fixes from 16.3. + For information about new features in major release 16, see + <xref linkend="release-16"/>. + </para> + + <sect2 id="release-16-4-migration"> + <title>Migration to Version 16.4</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.3, + see <xref linkend="release-16-3"/>. + </para> + </sect2> + + <sect2 id="release-16-4-changes"> + <title>Changes</title> + + <itemizedlist> + + <listitem> +<!-- +Author: Richard Guo <rguo@postgresql.org> +Branch: master [0ffc0acaf] 2024-07-08 10:11:46 +0900 +Branch: REL_17_STABLE [cccab85c2] 2024-07-08 10:17:12 +0900 +Branch: REL_16_STABLE [507f2347e] 2024-07-08 10:30:28 +0900 +--> + <para> + Avoid incorrect results from Merge Right Anti Join plans + (Richard Guo) + </para> + + <para> + If the inner relation is known to have unique join keys, the merge + could misbehave when there are duplicated join keys in the outer + relation. + </para> + </listitem> + + <listitem> +<!-- +Author: Melanie Plageman <melanieplageman@gmail.com> +Branch: master [83c39a1f7] 2024-07-19 12:04:00 -0400 +Branch: REL_17_STABLE [fd4f12df5] 2024-07-19 12:12:03 -0400 +Branch: REL_16_STABLE [06bf404cd] 2024-07-19 12:11:41 -0400 +Branch: REL_15_STABLE [dc6354c67] 2024-07-19 12:05:51 -0400 +Branch: REL_14_STABLE [45ce054c0] 2024-07-19 12:07:53 -0400 +--> + <para> + Prevent infinite loop in <command>VACUUM</command> + (Melanie Plageman) + </para> + + <para> + After a disconnected standby server with an old running transaction + reconnected to the primary, it was possible + for <command>VACUUM</command> on the primary to get confused about + which tuples are removable, resulting in an infinite loop. + </para> + </listitem> + + <listitem> +<!-- +Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +Branch: master [3dd637f3d] 2024-07-24 12:38:18 +0200 +Branch: REL_17_STABLE [2b22543a4] 2024-07-24 12:38:18 +0200 +Branch: REL_16_STABLE [084814d88] 2024-07-24 12:38:18 +0200 +Branch: REL_15_STABLE [f74fac06c] 2024-07-24 12:38:18 +0200 +Branch: REL_14_STABLE [fe1d16f66] 2024-07-24 12:38:18 +0200 +Branch: REL_13_STABLE [ed7430975] 2024-07-24 12:38:18 +0200 +Branch: REL_12_STABLE [08b6a9ecf] 2024-07-24 12:38:18 +0200 +--> + <para> + Fix failure after attaching a table as a partition, if the + table had previously had inheritance children + (Álvaro Herrera) + </para> + </listitem> + + <listitem> +<!-- +Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +Branch: master [839177913] 2024-07-12 12:54:01 +0200 +Branch: REL_17_STABLE [30ca4e1ab] 2024-07-12 12:54:01 +0200 +Branch: REL_16_STABLE [00a40e33c] 2024-07-12 12:54:01 +0200 +Branch: REL_15_STABLE [4ae09c59d] 2024-07-12 12:54:01 +0200 +Branch: REL_14_STABLE [66aaa7a71] 2024-07-12 12:54:01 +0200 +Branch: REL_13_STABLE [057482569] 2024-07-12 12:54:01 +0200 +Branch: REL_12_STABLE [d0054432d] 2024-07-12 12:54:01 +0200 +Branch: master [74e12db19] 2024-07-12 13:44:19 +0200 +Branch: REL_17_STABLE [0340eefd9] 2024-07-12 13:44:19 +0200 +Branch: REL_16_STABLE [34eb37f79] 2024-07-12 13:44:19 +0200 +Branch: REL_15_STABLE [9f0f72d89] 2024-07-12 13:44:19 +0200 +Branch: REL_14_STABLE [2f5007459] 2024-07-12 13:44:19 +0200 +Branch: REL_13_STABLE [7898a494f] 2024-07-12 13:44:19 +0200 +Branch: REL_12_STABLE [067cb6c5d] 2024-07-12 13:44:19 +0200 +--> + <para> + Fix <command>ALTER TABLE DETACH PARTITION</command> for cases + involving inconsistent index-based constraints + (Álvaro Herrera, Tender Wang) + </para> + + <para> + When a partitioned table has an index that is not associated with a + constraint, but a partition has an equivalent index that is, then + detaching the partition would misbehave, leaving the ex-partition's + constraint with an incorrect <structfield>coninhcount</structfield> + value. This would cause trouble during any further manipulations of + that constraint. + </para> + </listitem> + + <listitem> +<!-- +Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +Branch: master Release: REL_17_BR [27162a64b] 2024-06-24 15:56:32 +0200 +Branch: REL_16_STABLE [96105ebfe] 2024-06-24 15:56:32 +0200 +Branch: REL_15_STABLE [fb0fb0740] 2024-06-24 15:56:32 +0200 +Branch: REL_14_STABLE [66e569f50] 2024-06-24 15:56:32 +0200 +Branch: master Release: REL_17_BR [c2fab7024] 2024-06-11 11:38:45 +0200 +Branch: REL_16_STABLE [bf78abebf] 2024-06-11 11:38:45 +0200 +Branch: REL_15_STABLE [03c8cdbb7] 2024-06-11 11:38:45 +0200 +Branch: REL_14_STABLE [5dcaefc6a] 2024-06-11 11:38:45 +0200 +--> + <para> + Fix partition pruning setup during <literal>ALTER TABLE DETACH + PARTITION CONCURRENTLY</literal> (Álvaro Herrera) + </para> + + <para> + The executor assumed that no partition could be detached between + planning and execution of a query on a partitioned table. This is + no longer true since the introduction of <literal>DETACH + PARTITION</literal>'s <literal>CONCURRENTLY</literal> option, making + it possible for query execution to fail transiently when that is + used. + </para> + </listitem> + + <listitem> +<!-- +Author: Noah Misch <noah@leadboat.com> +Branch: master [710207032] 2024-07-13 08:09:33 -0700 +Branch: REL_17_STABLE [f5bb46fb2] 2024-07-13 08:09:36 -0700 +Branch: REL_16_STABLE [e81deeefc] 2024-07-13 08:09:37 -0700 +Branch: REL_15_STABLE [2b4a2a79e] 2024-07-13 08:09:37 -0700 +Branch: REL_14_STABLE [2b415e95a] 2024-07-13 08:09:37 -0700 +--> + <para> + Correctly update a partitioned table's + <structname>pg_class</structname>.<structfield>reltuples</structfield> + field to zero after its last child partition is dropped (Noah Misch) + </para> + + <para> + The first <command>ANALYZE</command> on such a partitioned table + must update <structfield>relhassubclass</structfield> as well, and + that caused the <structfield>reltuples</structfield> update to be + lost. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [f535f350c] 2024-05-14 20:19:20 -0400 +Branch: REL_16_STABLE [8e0e99972] 2024-05-14 20:19:20 -0400 +Branch: REL_15_STABLE [c40e78d23] 2024-05-14 20:19:20 -0400 +Branch: REL_14_STABLE [525bd1620] 2024-05-14 20:19:20 -0400 +Branch: REL_13_STABLE [e85f641b2] 2024-05-14 20:19:20 -0400 +Branch: REL_12_STABLE [70ffb27b2] 2024-05-14 20:19:20 -0400 +Branch: master Release: REL_17_BR [751598263] 2024-06-06 15:16:56 -0400 +Branch: REL_16_STABLE [bb331af4a] 2024-06-06 15:16:56 -0400 +Branch: REL_15_STABLE [5fe43d41d] 2024-06-06 15:16:56 -0400 +Branch: REL_14_STABLE [d88dcdf0f] 2024-06-06 15:16:56 -0400 +Branch: REL_13_STABLE [9de0ff91a] 2024-06-06 15:16:56 -0400 +Branch: REL_12_STABLE [4208f44c9] 2024-06-06 15:16:56 -0400 +--> + <para> + Fix handling of polymorphic output arguments for procedures + (Tom Lane) + </para> + + <para> + The SQL <command>CALL</command> statement did not resolve the + correct data types for such arguments, leading to errors such + as <quote>cannot display a value of type anyelement</quote>, or even + outright crashes. (But <command>CALL</command> + in <application>PL/pgSQL</application> worked correctly.) + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [2dc1deaea] 2024-06-07 13:27:26 -0400 +Branch: REL_16_STABLE [0d18b8eb4] 2024-06-07 13:27:26 -0400 +Branch: REL_15_STABLE [a160e9277] 2024-06-07 13:27:26 -0400 +Branch: REL_14_STABLE [0f7d1338c] 2024-06-07 13:27:26 -0400 +Branch: REL_13_STABLE [1d4ea1376] 2024-06-07 13:27:26 -0400 +Branch: REL_12_STABLE [0be81dd71] 2024-06-07 13:27:26 -0400 +--> + <para> + Fix behavior of stable functions called from + a <command>CALL</command> statement's argument list (Tom Lane) + </para> + + <para> + If the <command>CALL</command> is within an atomic context + (e.g. there's an outer transaction block), such functions were + passed the wrong snapshot, causing them to see stale values of rows + modified since the start of the outer transaction. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [a9a7c2c3e] 2024-05-22 18:22:58 -0400 +Branch: REL_16_STABLE [019ea7675] 2024-05-22 18:22:51 -0400 +--> + <para> + Fix input of ISO-8601 <quote>extended</quote> time format for + types <type>time</type> and <type>timetz</type> (Tom Lane) + </para> + + <para> + Re-allow cases such as <literal>T12:34:56</literal>. + </para> + </listitem> + + <listitem> +<!-- +Author: Nathan Bossart <nathan@postgresql.org> +Branch: master [22b0ccd65] 2024-07-19 11:52:32 -0500 +Branch: REL_17_STABLE [3764ee47f] 2024-07-19 11:52:32 -0500 +Branch: REL_16_STABLE [34e9dce69] 2024-07-19 11:52:32 -0500 +Branch: REL_15_STABLE [b82791c8f] 2024-07-19 11:52:32 -0500 +Branch: REL_14_STABLE [e8dfe0430] 2024-07-19 11:52:32 -0500 +Branch: REL_13_STABLE [c5321e965] 2024-07-19 11:52:32 -0500 +Branch: REL_12_STABLE [4f9628158] 2024-07-19 11:52:32 -0500 +--> + <para> + Detect integer overflow in <type>money</type> calculations + (Joseph Koshakow) + </para> + + <para> + None of the arithmetic functions for the <type>money</type> type + checked for overflow before, so they would silently give wrong + answers for overflowing cases. + </para> + </listitem> + + <listitem> +<!-- +Author: Dean Rasheed <dean.a.rasheed@gmail.com> +Branch: master [1ff39f4ff] 2024-07-08 17:48:45 +0100 +Branch: REL_17_STABLE [7a8977d25] 2024-07-08 17:51:23 +0100 +Branch: REL_16_STABLE [f7aec8c1d] 2024-07-08 17:52:52 +0100 +Branch: REL_15_STABLE [47ca912de] 2024-07-08 17:54:22 +0100 +Branch: REL_14_STABLE [a3c0124f6] 2024-07-08 17:55:31 +0100 +Branch: REL_13_STABLE [ece296926] 2024-07-08 17:56:51 +0100 +Branch: REL_12_STABLE [8badee787] 2024-07-08 17:58:42 +0100 +--> + <para> + Fix over-aggressive clamping of the scale argument + in <function>round(numeric)</function> + and <function>trunc(numeric)</function> (Dean Rasheed) + </para> + + <para> + These functions clamped their scale argument to +/-2000, but there + are valid use-cases for it to be larger; the functions returned + incorrect results in such cases. Instead clamp to the actual + allowed range of type <type>numeric</type>. + </para> + </listitem> + + <listitem> +<!-- +Author: David Rowley <drowley@postgresql.org> +Branch: master [b181062aa] 2024-07-28 22:22:52 +1200 +Branch: REL_17_STABLE [1e020258e] 2024-07-28 22:23:32 +1200 +Branch: REL_16_STABLE [6f6b0f193] 2024-07-28 22:23:54 +1200 +Branch: REL_15_STABLE [0a80e88d9] 2024-07-28 22:24:15 +1200 +--> + <para> + Fix result for <function>pg_size_pretty()</function> when applied to + the smallest possible <type>bigint</type> value (Joseph Koshakow) + </para> + </listitem> + + <listitem> +<!-- +Author: Nathan Bossart <nathan@postgresql.org> +Branch: master Release: REL_17_BR [3cb2f13ac] 2024-05-13 15:53:50 -0500 +Branch: REL_16_STABLE [c1664c8ee] 2024-05-13 15:54:04 -0500 +Branch: REL_15_STABLE [857d280c6] 2024-05-13 15:54:10 -0500 +Branch: REL_14_STABLE [c8714230a] 2024-05-13 15:54:14 -0500 +Branch: REL_13_STABLE [09ec5d455] 2024-05-13 15:54:18 -0500 +Branch: REL_12_STABLE [2812059d3] 2024-05-13 15:54:23 -0500 +--> + <para> + Prevent <function>pg_sequence_last_value()</function> from failing + on unlogged sequences on standby servers and on temporary sequences + of other sessions (Nathan Bossart) + </para> + + <para> + Make it return NULL in these cases instead of throwing an error. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [56a829621] 2024-06-13 20:35:02 -0400 +Branch: REL_16_STABLE [086ecd12b] 2024-06-13 20:35:02 -0400 +Branch: REL_15_STABLE [df95c1ec0] 2024-06-13 20:35:03 -0400 +Branch: REL_14_STABLE [5912bf77c] 2024-06-13 20:34:43 -0400 +Branch: REL_13_STABLE [c7de5a654] 2024-06-13 20:34:43 -0400 +Branch: REL_12_STABLE [5e63a6f43] 2024-06-13 20:34:43 -0400 +--> + <para> + Fix parsing of ignored operators + in <function>websearch_to_tsquery()</function> (Tom Lane) + </para> + + <para> + Per the manual, punctuation in the input + of <function>websearch_to_tsquery()</function> is ignored except for + the special cases of dashes and quotes. However, parentheses and a + few other characters appearing immediately before + an <literal>or</literal> could cause <literal>or</literal> to be + treated as a data word, rather than as an <literal>OR</literal> + operator as expected. + </para> + </listitem> + + <listitem> +<!-- +Author: Nathan Bossart <nathan@postgresql.org> +Branch: master [991f8cf8a] 2024-07-23 21:59:02 -0500 +Branch: REL_17_STABLE [657e54a05] 2024-07-23 21:59:02 -0500 +Branch: REL_16_STABLE [a57d16865] 2024-07-23 21:59:02 -0500 +Branch: REL_15_STABLE [547dd2cbd] 2024-07-23 21:59:02 -0500 +Branch: REL_14_STABLE [670fb9f18] 2024-07-23 21:59:02 -0500 +Branch: REL_13_STABLE [6c1b71bc6] 2024-07-23 21:59:02 -0500 +Branch: REL_12_STABLE [878e8c6be] 2024-07-23 21:59:02 -0500 +--> + <para> + Detect another integer overflow case while computing new array + dimensions (Joseph Koshakow) + </para> + + <para> + Reject applying array + dimensions <literal>[-2147483648:2147483647]</literal> to an empty + array. This is closely related to CVE-2023-5869, but appears + harmless since the array still ends up empty. + </para> + </listitem> + + <listitem> +<!-- +Author: Jeff Davis <jdavis@postgresql.org> +Branch: master [679c5084c] 2024-07-30 16:23:20 -0700 +Branch: REL_17_STABLE [10fdc67f8] 2024-07-30 16:25:03 -0700 +Branch: REL_16_STABLE [403cbd210] 2024-07-30 16:25:21 -0700 +--> + <para> + Fix unportable usage of <function>strnxfrm()</function> (Jeff Davis) + </para> + + <para> + Some code paths for non-deterministic collations could fail with + errors like <quote>pg_strnxfrm() returned unexpected result</quote>. + </para> + </listitem> + + <listitem> +<!-- +Author: Noah Misch <noah@leadboat.com> +Branch: master Release: REL_17_BR [f9f47f0d9] 2024-06-27 19:21:06 -0700 +Branch: REL_16_STABLE [e4afd7153] 2024-06-27 19:21:10 -0700 +Branch: REL_15_STABLE [b08a4b616] 2024-06-27 19:21:11 -0700 +Branch: REL_14_STABLE [af73e37fa] 2024-06-27 19:21:12 -0700 +Branch: REL_13_STABLE [7a21306ae] 2024-06-27 19:21:13 -0700 +Branch: REL_12_STABLE [11f3815d6] 2024-06-27 19:21:13 -0700 +--> + <para> + Detect another case of a new catalog cache entry becoming stale + while detoasting its fields (Noah Misch) + </para> + + <para> + An in-place update occurring while we expand out-of-line fields in a + catalog tuple could be missed, leading to a catalog cache entry that + lacks the in-place change but is not known to be stale. This is + only possible in the <structname>pg_database</structname> catalog, + so the effects are narrow, but misbehavior is possible. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master [220003b9b] 2024-07-20 13:40:15 -0400 +Branch: REL_17_STABLE [041a00c48] 2024-07-20 13:40:15 -0400 +Branch: REL_16_STABLE [fd958bbbd] 2024-07-20 13:40:15 -0400 +Branch: REL_15_STABLE [96953052a] 2024-07-20 13:40:15 -0400 +Branch: REL_14_STABLE [0d712ec12] 2024-07-20 13:40:15 -0400 +Branch: REL_13_STABLE [461f47948] 2024-07-20 13:40:15 -0400 +Branch: REL_12_STABLE [feca6c688] 2024-07-20 13:40:15 -0400 +--> + <para> + Correctly check updatability of view columns targeted + by <literal>INSERT</literal> ... <literal>DEFAULT</literal> + (Tom Lane) + </para> + + <para> + If such a column is non-updatable, we should give an error reporting + that. But the check was missed and then later code would report an + unhelpful error such as <quote>attribute + number <replaceable>N</replaceable> not found in view + targetlist</quote>. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master [f96c2c727] 2024-07-14 13:49:46 -0400 +Branch: REL_17_STABLE [cf588e10f] 2024-07-14 13:49:46 -0400 +Branch: REL_16_STABLE [8fc487614] 2024-07-14 13:49:46 -0400 +Branch: REL_15_STABLE [e7f9f44e3] 2024-07-14 13:49:46 -0400 +Branch: REL_14_STABLE [02b4f5e1f] 2024-07-14 13:49:46 -0400 +Branch: REL_13_STABLE [b020a866a] 2024-07-14 13:49:46 -0400 +Branch: REL_12_STABLE [236b225ed] 2024-07-14 13:49:46 -0400 +--> + <para> + Avoid reporting an unhelpful internal error for incorrect recursive + queries (Tom Lane) + </para> + + <para> + Rearrange the order of error checks so that we throw an on-point + error when a <command>WITH RECURSIVE</command> query does not have a + self-reference within the second arm of + the <literal>UNION</literal>, but does have one self-reference in + some other place such as <literal>ORDER BY</literal>. + </para> + </listitem> + + <listitem> +<!-- +Author: Noah Misch <noah@leadboat.com> +Branch: master Release: REL_17_BR [f88cdb36c] 2024-06-27 19:21:05 -0700 +Branch: REL_16_STABLE [112d05570] 2024-06-27 19:21:09 -0700 +Branch: REL_15_STABLE [24561b498] 2024-06-27 19:21:10 -0700 +--> + <para> + Lock owned sequences during <literal>ALTER TABLE SET + LOGGED|UNLOGGED</literal> (Noah Misch) + </para> + + <para> + These commands change the persistence of a table's owned sequences + along with the table, but they failed to acquire lock on the + sequences while doing so. This could result in losing the effects + of concurrent <function>nextval()</function> calls. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [e6d0d16ad] 2024-06-20 14:21:36 -0400 +Branch: REL_16_STABLE [4f1966676] 2024-06-20 14:21:36 -0400 +Branch: REL_15_STABLE [1424c7abc] 2024-06-20 14:21:36 -0400 +Branch: REL_14_STABLE [88f3baa06] 2024-06-20 14:21:36 -0400 +Branch: REL_13_STABLE [9ce8ee9d3] 2024-06-20 14:21:36 -0400 +Branch: REL_12_STABLE [b0037bbef] 2024-06-20 14:21:36 -0400 +--> + <para> + Don't throw an error if a queued <literal>AFTER</literal> trigger no + longer exists (Tom Lane) + </para> + + <para> + It's possible for a transaction to execute an operation that queues + a deferred <literal>AFTER</literal> trigger for later execution, and + then to drop the trigger before that happens. Formerly this led to + weird errors such as <quote>could not find + trigger <replaceable>NNNN</replaceable></quote>. It seems better to + silently do nothing if the trigger no longer exists at the time when + it would have been executed. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [76618097a] 2024-06-14 16:20:35 -0400 +Branch: REL_16_STABLE [9cf4beb9e] 2024-06-14 16:20:35 -0400 +Branch: REL_15_STABLE [1f1eedd3f] 2024-06-14 16:20:35 -0400 +Branch: REL_14_STABLE [f3f6a14ce] 2024-06-14 16:20:35 -0400 +Branch: REL_13_STABLE [198de7961] 2024-06-14 16:20:35 -0400 +Branch: REL_12_STABLE [0a39343ae] 2024-06-14 16:20:35 -0400 +--> + <para> + Fix failure to remove <structname>pg_init_privs</structname> entries + for column-level privileges when their table is dropped (Tom Lane) + </para> + + <para> + If an extension grants some column-level privileges on a table it + creates, relevant catalog entries would remain behind after the + extension is dropped. This was harmless until/unless the table's + OID was re-used for another relation, when it could interfere with + what <application>pg_dump</application> dumps for that relation. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [915de706d] 2024-06-11 17:57:46 -0400 +Branch: REL_16_STABLE [b188e1bf7] 2024-06-11 17:57:46 -0400 +Branch: REL_15_STABLE [1d0399b54] 2024-06-11 17:57:46 -0400 +Branch: REL_14_STABLE [096f2132c] 2024-06-11 17:57:46 -0400 +Branch: REL_13_STABLE [5e8aa32a9] 2024-06-11 17:57:46 -0400 +Branch: REL_12_STABLE [9256bf6eb] 2024-06-11 17:57:46 -0400 +--> + <para> + Fix selection of an arbiter index for <literal>ON CONFLICT</literal> + when the desired index has expressions or predicates (Tom Lane) + </para> + + <para> + If a query using <literal>ON CONFLICT</literal> accesses the target + table through an updatable view, it could fail with <quote>there is + no unique or exclusion constraint matching the ON CONFLICT + specification</quote>, even though a matching index does exist. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [7ed8ce8a4] 2024-06-07 14:50:09 -0400 +Branch: REL_16_STABLE [8397f161e] 2024-06-07 14:50:09 -0400 +Branch: REL_15_STABLE [3c71cb497] 2024-06-07 14:50:09 -0400 +Branch: REL_14_STABLE [2dad0f433] 2024-06-07 14:50:09 -0400 +Branch: REL_13_STABLE [7c4ac652e] 2024-06-07 14:50:09 -0400 +Branch: REL_12_STABLE [b8efd756d] 2024-06-07 14:50:09 -0400 +--> + <para> + Refuse to modify a temporary table of another session + with <literal>ALTER TABLE</literal> (Tom Lane) + </para> + + <para> + Permissions checks normally would prevent this case from arising, + but it is possible to reach it by altering a parent table whose + child is another session's temporary table. Throw an error if we + discover that such a child table belongs to another session. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [5278668d7] 2024-05-22 17:54:17 -0400 +Branch: REL_16_STABLE [2aa90c02d] 2024-05-22 17:54:17 -0400 +Branch: REL_15_STABLE [2f3cfcf76] 2024-05-22 17:54:17 -0400 +Branch: REL_14_STABLE [1015162c3] 2024-05-22 17:54:17 -0400 +--> + <para> + Fix handling of extended statistics on expressions + in <literal>CREATE TABLE LIKE STATISTICS</literal> (Tom Lane) + </para> + + <para> + The <literal>CREATE</literal> command failed to adjust column + references in statistics expressions to the possibly-different + column numbering of the new table. This resulted in invalid + statistics objects that would cause problems later. A typical + scenario where renumbering columns is needed is when the source + table contains some dropped columns. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [d0d44049d] 2023-07-14 11:41:20 -0400 +Branch: master Release: REL_17_BR [779ac2c74] 2024-05-18 14:26:13 -0400 +Branch: REL_16_STABLE [ce0d16544] 2024-05-18 14:31:35 -0400 +Branch: REL_15_STABLE [4ac385adc] 2024-05-18 14:31:35 -0400 +Branch: REL_14_STABLE [5ac340602] 2024-05-18 14:31:35 -0400 +Branch: REL_13_STABLE [7f90a5dc3] 2024-05-18 14:31:35 -0400 +Branch: REL_12_STABLE [686c995fc] 2024-05-18 14:31:35 -0400 +--> + <para> + Fix failure to recalculate sub-queries generated + from <function>MIN()</function> or <function>MAX()</function> + aggregates (Tom Lane) + </para> + + <para> + In some cases the aggregate result computed at one row of the outer + query could be re-used for later rows when it should not be. This + has only been seen to happen when the outer query uses + <literal>DISTINCT</literal> that is implemented with hash + aggregation, but other cases may exist. + </para> + </listitem> + + <listitem> +<!-- +Author: Peter Eisentraut <peter@eisentraut.org> +Branch: master Release: REL_17_BR [98b4f53d1] 2024-05-15 13:49:41 +0200 +Branch: REL_16_STABLE [315661eca] 2024-05-15 13:54:00 +0200 +--> + <para> + Re-forbid underscore in positional parameters (Erik Wienhold) + </para> + + <para> + As of v16 we allow integer literals to contain underscores. + This change caused input such as <literal>$1_234</literal> + to be taken as a single token, but it did not work correctly. + It seems better to revert to the original definition in which a + parameter symbol is only <literal>$</literal> followed by digits. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [5d6c64d29] 2024-06-27 14:44:02 -0400 +Branch: REL_16_STABLE [07d66d3cc] 2024-06-27 14:44:02 -0400 +Branch: REL_15_STABLE [5401e70e4] 2024-06-27 14:44:03 -0400 +Branch: REL_14_STABLE [13abc1f66] 2024-06-27 14:44:03 -0400 +Branch: REL_13_STABLE [86fac88ee] 2024-06-27 14:44:03 -0400 +Branch: REL_12_STABLE [dccda847b] 2024-06-27 14:44:04 -0400 +--> + <para> + Avoid crashing when a JIT-inlined backend function throws an error + (Tom Lane) + </para> + + <para> + The error state can include pointers into the dynamically loaded + module holding the JIT-compiled code (for error location strings). + In some code paths the module could get unloaded before the error + report is processed, leading to SIGSEGV when the location strings + are accessed. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master [066e8ac6e] 2024-07-06 15:16:13 -0400 +Branch: master [6082b3d5d] 2024-07-08 14:04:00 -0400 +Branch: master [e7192486d] 2024-07-09 15:01:13 -0400 +Branch: master [896cd266f] 2024-07-09 16:31:24 -0400 +Branch: REL_17_STABLE [a9747be27] 2024-07-10 20:15:52 -0400 +Branch: REL_16_STABLE [f85c91a18] 2024-07-10 20:15:52 -0400 +Branch: REL_15_STABLE [f68d6aabb] 2024-07-10 20:15:52 -0400 +Branch: REL_14_STABLE [475e1807c] 2024-07-10 20:15:52 -0400 +Branch: REL_13_STABLE [48132587d] 2024-07-10 20:15:52 -0400 +Branch: REL_12_STABLE [a134baea7] 2024-07-10 20:15:52 -0400 +--> + <para> + Cope with behavioral changes in <application>libxml2</application> + version 2.13.x (Erik Wienhold, Tom Lane) + </para> + + <para> + Notably, we now suppress <quote>chunk is not well balanced</quote> + errors from <application>libxml2</application>, unless that is the + only reported error. This is to make error reports consistent + between 2.13.x and earlier <application>libxml2</application> + versions. In earlier versions, that message was almost always + redundant or outright incorrect, so 2.13.x substantially reduced the + number of cases in which it's reported. + </para> + </listitem> + + <listitem> +<!-- +Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> +Branch: master Release: REL_17_BR [cbfbda784] 2024-06-27 21:09:58 +0300 +Branch: REL_16_STABLE [b5b418b68] 2024-06-27 21:10:27 +0300 +Branch: REL_15_STABLE [0e2f3d78b] 2024-06-27 21:10:31 +0300 +Branch: REL_14_STABLE [9dbf8ab48] 2024-06-27 21:10:34 +0300 +Branch: REL_13_STABLE [e9c8747ee] 2024-06-27 21:08:55 +0300 +Branch: REL_12_STABLE [5dea6628b] 2024-06-27 21:09:15 +0300 +--> + <para> + Fix handling of subtransactions of prepared transactions + when starting a hot standby server (Heikki Linnakangas) + </para> + + <para> + When starting a standby's replay at a shutdown checkpoint WAL + record, transactions that had been prepared but not yet committed on + the primary are correctly understood as being still in progress. + But subtransactions of a prepared transaction (created by savepoints + or <application>PL/pgSQL</application> exception blocks) were not + accounted for and would be treated as aborted. That led to + inconsistency if the prepared transaction was later committed. + </para> + </listitem> + + <listitem> +<!-- +Author: Masahiko Sawada <msawada@postgresql.org> +Branch: master [bb19b7008] 2024-07-11 22:48:23 +0900 +Branch: REL_17_STABLE [068674f4a] 2024-07-11 22:48:21 +0900 +Branch: REL_16_STABLE [2f3304ce1] 2024-07-11 22:48:18 +0900 +Branch: REL_15_STABLE [aee8c2b95] 2024-07-11 22:48:16 +0900 +Branch: REL_14_STABLE [f7d3caf9d] 2024-07-11 22:48:13 +0900 +Branch: REL_13_STABLE [cf2c69ec5] 2024-07-11 22:48:10 +0900 +Branch: REL_12_STABLE [1b3707587] 2024-07-11 22:48:08 +0900 +--> + <para> + Prevent incorrect initialization of logical replication slots + (Masahiko Sawada) + </para> + + <para> + In some cases a replication slot's start point within the WAL stream + could be set to a point within a transaction, leading to assertion + failures or incorrect decoding results. + </para> + </listitem> + + <listitem> +<!-- +Author: Michael Paquier <michael@paquier.xyz> +Branch: master Release: REL_17_BR [cd312adc5] 2024-06-06 08:47:40 +0900 +Branch: REL_16_STABLE [f2c922ff2] 2024-06-06 08:48:17 +0900 +Branch: REL_15_STABLE [bfc44da24] 2024-06-06 08:48:21 +0900 +--> + <para> + Avoid <quote>can only drop stats once</quote> error during + replication slot creation and drop (Floris Van Nee) + </para> + </listitem> + + <listitem> +<!-- +Author: Amit Kapila <akapila@postgresql.org> +Branch: master Release: REL_17_BR [3e53492aa] 2024-06-27 11:35:00 +0530 +Branch: REL_16_STABLE [b8f953d8d] 2024-06-27 11:19:57 +0530 +Branch: REL_15_STABLE [76fda6140] 2024-06-27 10:43:52 +0530 +--> + <para> + Fix resource leakage in logical replication WAL sender (Hou Zhijie) + </para> + + <para> + The walsender process leaked memory when publishing changes to a + partitioned table whose partitions have row types physically + different from the partitioned table's. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: REL_17_STABLE [31f8d620b] 2024-07-01 12:21:07 -0400 +Branch: REL_16_STABLE [54a7b21b3] 2024-07-01 12:21:07 -0400 +Branch: REL_15_STABLE [4df767cf9] 2024-07-01 12:21:07 -0400 +Branch: REL_14_STABLE [1608902fc] 2024-07-01 12:21:07 -0400 +Branch: REL_13_STABLE [5f86cd70d] 2024-07-01 12:21:07 -0400 +Branch: REL_12_STABLE [8565fb6fb] 2024-07-01 12:21:07 -0400 +--> + <para> + Avoid memory leakage after servicing a notify or sinval interrupt + (Tom Lane) + </para> + + <para> + The processing functions for these events could switch the current + memory context to TopMemoryContext, resulting in session-lifespan + leakage of any data allocated before the incorrect setting gets + replaced. There were observable leaks associated with (at least) + encoding conversion of incoming queries and parameters attached to + Bind messages. + </para> + </listitem> + + <listitem> +<!-- +Author: Michael Paquier <michael@paquier.xyz> +Branch: master Release: REL_17_BR [7467939ea] 2024-06-27 09:44:47 +0900 +Branch: REL_16_STABLE [6f61d0e7e] 2024-06-27 09:44:51 +0900 +Branch: REL_15_STABLE [eb144dfca] 2024-06-27 09:44:55 +0900 +--> + <para> + Prevent leakage of reference counts for the shared memory block used + for statistics (Anthonin Bonnefoy) + </para> + + <para> + A new backend process attaching to the statistics shared memory + incremented its reference count, but failed to decrement the count + when exiting. After 2<superscript>32</superscript> sessions had + been created, the reference count would overflow to zero, causing + failures in all subsequent backend process starts. + </para> + </listitem> + + <listitem> +<!-- +Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> +Branch: master Release: REL_17_BR [b1ffe3ff0] 2024-06-26 23:02:06 +0300 +Branch: REL_16_STABLE [e7cbe5a85] 2024-06-26 23:04:36 +0300 +Branch: REL_15_STABLE [c809a2b2d] 2024-06-26 23:05:58 +0300 +Branch: REL_14_STABLE [4c8e00ae9] 2024-06-26 23:06:12 +0300 +--> + <para> + Prevent deadlocks and assertion failures during truncation of the + multixact SLRU log (Heikki Linnakangas) + </para> + + <para> + A process trying to delete SLRU segments could deadlock with the + checkpointer process. + </para> + </listitem> + + <listitem> +<!-- +Author: Thomas Munro <tmunro@postgresql.org> +Branch: master [a8458f508] 2024-07-13 14:59:46 +1200 +Branch: REL_17_STABLE [3c1c82d40] 2024-07-13 15:02:33 +1200 +Branch: REL_16_STABLE [a622095bc] 2024-07-13 15:27:35 +1200 +Branch: REL_15_STABLE [5546a834c] 2024-07-13 15:28:38 +1200 +Branch: REL_14_STABLE [894b497ac] 2024-07-13 15:43:43 +1200 +Branch: REL_13_STABLE [3554d841d] 2024-07-13 15:44:11 +1200 +Branch: REL_12_STABLE [ba9fcac72] 2024-07-13 15:45:28 +1200 +--> + <para> + Avoid possibly missing end-of-input events on Windows sockets + (Thomas Munro) + </para> + + <para> + Windows reports an FD_CLOSE event only once after the remote end of + the connection disconnects. With unlucky timing, we could miss that + report and wait indefinitely, or at least until a timeout elapsed, + expecting more input. + </para> + </listitem> + + <listitem> +<!-- +Author: Michael Paquier <michael@paquier.xyz> +Branch: master Release: REL_17_BR [855517307] 2024-05-09 12:45:37 +0900 +Branch: REL_16_STABLE [5396a2987] 2024-05-09 12:45:43 +0900 +Branch: REL_15_STABLE [8c3f30e67] 2024-05-09 12:45:45 +0900 +Branch: REL_14_STABLE [41adf9d96] 2024-05-09 12:45:48 +0900 +Branch: REL_13_STABLE [377c25d32] 2024-05-09 12:45:51 +0900 +--> + <para> + Fix buffer overread in JSON parse error reports for incomplete byte + sequences (Jacob Champion) + </para> + + <para> + It was possible to walk off the end of the input buffer by a few + bytes when the last bytes comprise an incomplete multi-byte + character. While usually harmless, in principle this could cause a + crash. + </para> + </listitem> + + <listitem> +<!-- +Author: Daniel Gustafsson <dgustafsson@postgresql.org> +Branch: master [274bbced8] 2024-07-26 11:09:45 +0200 +Branch: REL_17_STABLE [3df7f44a8] 2024-07-26 11:09:45 +0200 +Branch: REL_16_STABLE [cc606afce] 2024-07-26 11:09:45 +0200 +Branch: REL_15_STABLE [118ec331b] 2024-07-26 11:09:45 +0200 +Branch: REL_14_STABLE [ecbb1cd9b] 2024-07-26 11:09:45 +0200 +Branch: REL_13_STABLE [1f476bc75] 2024-07-26 11:09:45 +0200 +Branch: REL_12_STABLE [32121c077] 2024-07-26 11:09:45 +0200 +Branch: master [161c73462] 2024-07-26 16:25:28 +0200 +Branch: REL_17_STABLE [1272cfb72] 2024-07-26 16:25:56 +0200 +Branch: REL_16_STABLE [83b4a6358] 2024-07-26 16:29:47 +0200 +Branch: REL_15_STABLE [970cd5c62] 2024-07-26 14:16:40 +0200 +Branch: REL_14_STABLE [51c1b4fd1] 2024-07-26 14:16:40 +0200 +Branch: REL_13_STABLE [40e8ea949] 2024-07-26 14:16:40 +0200 +Branch: REL_12_STABLE [ac77add23] 2024-07-26 14:16:40 +0200 +Branch: REL_16_STABLE [441eba34d] 2024-07-26 16:29:52 +0200 +Branch: REL_15_STABLE [ce3045e9b] 2024-07-26 19:09:27 +0200 +Branch: REL_14_STABLE [ddd66a629] 2024-07-26 19:09:54 +0200 +Branch: REL_13_STABLE [634710dfb] 2024-07-26 19:10:12 +0200 +Branch: REL_12_STABLE [e6dd0b863] 2024-07-26 19:10:37 +0200 +--> + <para> + Disable creation of stateful TLS session tickets by OpenSSL + (Daniel Gustafsson) + </para> + + <para> + This avoids possible failures with clients that think receipt of + a session ticket means that TLS session resumption is supported. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [6dfac2440] 2024-06-13 13:37:49 -0400 +Branch: REL_16_STABLE [82a931d3d] 2024-06-13 13:37:49 -0400 +Branch: REL_15_STABLE [bf552b1b2] 2024-06-13 13:37:50 -0400 +Branch: REL_14_STABLE [1450db793] 2024-06-13 13:37:50 -0400 +Branch: REL_13_STABLE [1fa46dba5] 2024-06-13 13:37:50 -0400 +Branch: REL_12_STABLE [ec210914c] 2024-06-13 13:37:51 -0400 +--> + <para> + When replanning a <application>PL/pgSQL</application> <quote>simple + expression</quote>, check it's still simple (Tom Lane) + </para> + + <para> + Certain fairly-artificial cases, such as dropping a referenced + function and recreating it as an aggregate, could lead to surprising + failures such as <quote>unexpected plan node type</quote>. + </para> + </listitem> + + <listitem> +<!-- +Author: Dean Rasheed <dean.a.rasheed@gmail.com> +Branch: master Release: REL_17_BR [cd2624fd9] 2024-06-04 11:48:01 +0100 +Branch: REL_16_STABLE [b4e909082] 2024-06-04 11:51:25 +0100 +--> + <para> + Fix <application>PL/pgSQL</application>'s handling of integer ranges + containing underscores (Erik Wienhold) + </para> + + <para> + As of v16 we allow integer literals to contain underscores, + but <application>PL/pgSQL</application> failed to handle examples + such as <literal>FOR i IN 1_001..1_003</literal>. + </para> + </listitem> + + <listitem> +<!-- +Author: Andrew Dunstan <andrew@dunslane.net> +Branch: REL_15_STABLE [f853e23bf] 2024-06-26 07:01:47 -0400 +Branch: REL_14_STABLE [20f22e6a6] 2024-06-26 07:24:35 -0400 +Branch: REL_13_STABLE [b7374f15b] 2024-06-26 07:25:00 -0400 +Branch: REL_12_STABLE [ab46e132f] 2024-06-26 07:25:10 -0400 +Branch: REL_11_STABLE [e1541d518] 2024-06-26 07:25:26 -0400 +Branch: REL_10_STABLE [320534f8f] 2024-06-26 07:25:35 -0400 +Branch: REL9_6_STABLE [12c8faaa7] 2024-06-26 07:29:31 -0400 +Branch: REL9_5_STABLE [0536f8e2c] 2024-06-26 07:30:01 -0400 +Branch: REL9_4_STABLE [8851d5c3a] 2024-06-26 07:30:06 -0400 +Branch: REL9_3_STABLE [8f3be9661] 2024-06-26 07:30:11 -0400 +Branch: REL9_2_STABLE [1c4173116] 2024-06-26 07:32:15 -0400 +--> + <para> + Fix incompatibility between <application>PL/Perl</application> and + Perl 5.40 (Andrew Dunstan) + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [d727c5431] 2024-05-09 13:16:34 -0400 +Branch: REL_16_STABLE [52ea653aa] 2024-05-09 13:16:21 -0400 +Branch: REL_15_STABLE [6e29963ed] 2024-05-09 13:16:21 -0400 +Branch: REL_14_STABLE [d39337021] 2024-05-09 13:16:21 -0400 +Branch: REL_13_STABLE [272867792] 2024-05-09 13:16:21 -0400 +Branch: REL_12_STABLE [157b1e6b4] 2024-05-09 13:16:21 -0400 +--> + <para> + Fix recursive <type>RECORD</type>-returning + <application>PL/Python</application> functions (Tom Lane) + </para> + + <para> + If we recurse to a new call of the same function that passes a + different column definition list (<literal>AS</literal> clause), it + would fail because the inner call would overwrite the outer call's + idea of what rowtype to return. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [c5bec5426] 2024-05-07 18:15:00 -0400 +Branch: REL_16_STABLE [be18a12b6] 2024-05-07 18:15:00 -0400 +Branch: REL_15_STABLE [363e8c2f9] 2024-05-07 18:15:00 -0400 +Branch: REL_14_STABLE [90d39929a] 2024-05-07 18:15:00 -0400 +Branch: REL_13_STABLE [abe60b6a0] 2024-05-07 18:15:00 -0400 +Branch: REL_12_STABLE [4488142a4] 2024-05-07 18:15:00 -0400 +--> + <para> + Don't corrupt <application>PL/Python</application>'s + <literal>TD</literal> dictionary during a recursive trigger call + (Tom Lane) + </para> + + <para> + If a <application>PL/Python</application>-language trigger caused + another one to be invoked, the <literal>TD</literal> dictionary + created for the inner one would overwrite the outer + one's <literal>TD</literal> dictionary. + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [b631d0149] 2024-06-04 18:02:13 -0400 +Branch: REL_16_STABLE [c236ecc82] 2024-06-04 18:02:13 -0400 +Branch: REL_15_STABLE [89ef2aeda] 2024-06-04 18:02:13 -0400 +Branch: REL_14_STABLE [1488dee08] 2024-06-04 18:02:13 -0400 +Branch: REL_13_STABLE [dda633a03] 2024-06-04 18:02:13 -0400 +Branch: REL_12_STABLE [30487423c] 2024-06-04 18:02:13 -0400 +--> + <para> + Fix <application>PL/Tcl</application>'s reporting of invalid list + syntax in the result of a function returning tuple (Erik Wienhold, + Tom Lane) + </para> + + <para> + Such a case could result in a crash, or in emission of misleading + context information that actually refers to the previous Tcl error. + </para> + </listitem> + + <listitem> +<!-- +Author: Peter Eisentraut <peter@eisentraut.org> +Branch: master [1e666fd7c] 2024-07-28 09:23:24 +0200 +Branch: REL_17_STABLE [821fbd63e] 2024-07-28 10:19:57 +0200 +Branch: REL_16_STABLE [c53016860] 2024-07-28 09:25:03 +0200 +Branch: REL_15_STABLE [6ddc8556c] 2024-07-28 09:25:52 +0200 +Branch: REL_14_STABLE [95e805e9c] 2024-07-28 09:26:21 +0200 +Branch: REL_13_STABLE [da5d7a771] 2024-07-28 09:26:39 +0200 +Branch: REL_12_STABLE [407048999] 2024-07-28 09:26:48 +0200 +--> + <para> + Avoid non-thread-safe usage of <function>strerror()</function> + in <application>libpq</application> (Peter Eisentraut) + </para> + + <para> + Certain error messages returned by OpenSSL could become garbled in + multi-threaded applications. + </para> + </listitem> + + <listitem> +<!-- +Author: Daniel Gustafsson <dgustafsson@postgresql.org> +Branch: master Release: REL_17_BR [a8f87d5d2] 2024-05-15 22:48:51 +0200 +Branch: REL_16_STABLE [0ae05c18e] 2024-05-15 22:48:51 +0200 +Branch: REL_15_STABLE [e6fc3b70d] 2024-05-15 22:48:51 +0200 +--> + <para> + Avoid memory leak within <application>pg_dump</application> during a + binary upgrade (Daniel Gustafsson) + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [c1aea206e] 2024-05-07 18:22:52 -0400 +Branch: REL_16_STABLE [5dce8ce0a] 2024-05-07 18:23:01 -0400 +Branch: REL_15_STABLE [6a458d93b] 2024-05-07 18:23:07 -0400 +Branch: REL_14_STABLE [52b23b4e1] 2024-05-07 18:23:11 -0400 +Branch: REL_13_STABLE [b99dc6694] 2024-05-07 18:23:15 -0400 +Branch: REL_12_STABLE [a3c00ab15] 2024-05-07 18:23:20 -0400 +--> + <para> + Ensure that <literal>pg_restore</literal> <option>-l</option> + reports dependent TOC entries correctly (Tom Lane) + </para> + + <para> + If <option>-l</option> was specified together with selective-restore + options such as <option>-n</option> or <option>-N</option>, + dependent TOC entries such as comments would be omitted from the + listing, even when an actual restore would have selected them. + </para> + </listitem> + + <listitem> +<!-- +Author: Michael Paquier <michael@paquier.xyz> +Branch: master [c145f321b] 2024-07-19 10:21:01 +0900 +Branch: REL_17_STABLE [38e271d3c] 2024-07-19 10:21:21 +0900 +Branch: REL_16_STABLE [9cd365f28] 2024-07-19 10:21:24 +0900 +--> + <para> + Allow <filename>contrib/pg_stat_statements</filename> to distinguish + among utility statements appearing within SQL-language functions + (Anthonin Bonnefoy) + </para> + + <para> + The SQL-language function executor failed to pass along the query ID + that is computed for a utility + (non <command>SELECT</command>/<command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>/<command>MERGE</command>) + statement. + </para> + </listitem> + + <listitem> +<!-- +Author: Etsuro Fujita <efujita@postgresql.org> +Branch: master [5c571a34d] 2024-07-19 13:15:00 +0900 +Branch: REL_17_STABLE [935fe79ea] 2024-07-19 13:15:01 +0900 +Branch: REL_16_STABLE [d97f2ee50] 2024-07-19 13:15:03 +0900 +Branch: REL_15_STABLE [f39f3e0fb] 2024-07-19 13:15:05 +0900 +--> + <para> + Avoid <quote>cursor can only scan forward</quote> error + in <filename>contrib/postgres_fdw</filename> (Etsuro Fujita) + </para> + + <para> + This error could occur if the remote server is v15 or later + and a foreign table is mapped to a non-trivial remote view. + </para> + </listitem> + + <listitem> +<!-- +Author: Etsuro Fujita <efujita@postgresql.org> +Branch: master Release: REL_17_BR [8cfbac149] 2024-06-07 17:45:00 +0900 +Branch: REL_16_STABLE [8405d5a37] 2024-06-07 17:45:02 +0900 +Branch: REL_15_STABLE [b33c141cc] 2024-06-07 17:45:04 +0900 +Branch: REL_14_STABLE [269e2c391] 2024-06-07 17:45:06 +0900 +Branch: REL_13_STABLE [2b461efc5] 2024-06-07 17:45:08 +0900 +--> + <para> + In <filename>contrib/postgres_fdw</filename>, do not + send <literal>FETCH FIRST WITH TIES</literal> clauses to the remote + server (Japin Li) + </para> + + <para> + The remote server might not implement this clause, or might + interpret it differently than we would locally, so don't risk + attempting remote execution. + </para> + </listitem> + + <listitem> +<!-- +Author: Thomas Munro <tmunro@postgresql.org> +Branch: master [2a5ef0983] 2024-07-06 10:27:16 +1200 +Branch: REL_17_STABLE [9c273679b] 2024-07-06 11:23:40 +1200 +Branch: REL_16_STABLE [31423bc44] 2024-07-06 11:18:29 +1200 +Branch: REL_15_STABLE [467d77bb1] 2024-07-06 10:53:13 +1200 +Branch: REL_14_STABLE [c2342a925] 2024-07-06 10:44:41 +1200 +Branch: REL_13_STABLE [440aedc0f] 2024-07-06 10:39:10 +1200 +Branch: REL_12_STABLE [274a8195d] 2024-07-06 10:30:03 +1200 +--> + <para> + Avoid clashing with + system-provided <filename><regex.h></filename> headers + (Thomas Munro) + </para> + + <para> + This fixes a compilation failure on macOS version 15 and up. + </para> + </listitem> + + <listitem> +<!-- +Author: David Rowley <drowley@postgresql.org> +Branch: master Release: REL_17_BR [aa901a37c] 2024-06-19 10:20:24 +1200 +Branch: REL_16_STABLE [6143c9c03] 2024-06-19 10:21:00 +1200 +Branch: REL_15_STABLE [27c6242a0] 2024-06-19 10:21:26 +1200 +Branch: REL_14_STABLE [dae9f16aa] 2024-06-19 10:21:52 +1200 +--> + <para> + Fix otherwise-harmless assertion failure in Memoize cost estimation + (David Rowley) + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master Release: REL_17_BR [92c49d106] 2024-06-17 14:30:59 -0400 +Branch: REL_16_STABLE [06f81fed3] 2024-06-17 14:30:59 -0400 +Branch: REL_15_STABLE [f55083319] 2024-06-17 14:30:59 -0400 +Branch: REL_14_STABLE [e4a55378f] 2024-06-17 14:30:59 -0400 +Branch: REL_13_STABLE [507a900ad] 2024-06-17 14:30:59 -0400 +Branch: REL_12_STABLE [3e3e2ebea] 2024-06-17 14:30:59 -0400 +--> + <para> + Fix otherwise-harmless assertion failures in <literal>REINDEX + CONCURRENTLY</literal> applied to an SP-GiST index (Tom Lane) + </para> + </listitem> + + </itemizedlist> + + </sect2> + </sect1> + <sect1 id="release-16-3"> <title>Release 16.3</title>