database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-12 21:01:52 +03:00
Code Activity

Release notes for 16.4, 15.8, 14.13, 13.16, 12.20.

Browse Source
This commit is contained in:
Tom Lane
2024-08-04 13:38:59 -04:00
parent fba8305733
commit 29337a5ff7
1 changed files with 845 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

845
doc/src/sgml/release-12.sgml
View File

@ -1,6 +1,851 @@
<!-- doc/src/sgml/release-12.sgml --> <!-- doc/src/sgml/release-12.sgml -->
<!-- See header comment in release.sgml about typical markup --> <!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-12-20">
<title>Release 12.20</title>
<formalpara>
<title>Release date:</title>
<para>2024-08-08</para>
</formalpara>
<para>
This release contains a variety of fixes from 12.19.
For information about new features in major release 12, see
<xref linkend="release-12"/>.
</para>
<para>
The <productname>PostgreSQL</productname> community will stop
releasing updates for the 12.X release series in November 2024.
Users are encouraged to update to a newer release branch soon.
</para>
<sect2>
<title>Migration to Version 12.20</title>
<para>
A dump/restore is not required for those running 12.X.
</para>
<para>
However, if you are upgrading from a version earlier than 12.18,
see <xref linkend="release-12-18"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<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
(&Aacute;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
(&Aacute;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: 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: 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: 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: 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: 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 [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: 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: 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: 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: 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: 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: 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: 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>&lt;regex.h&gt;</filename> headers
(Thomas Munro)
</para>
<para>
This fixes a compilation failure on macOS version 15 and up.
</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-12-19"> <sect1 id="release-12-19">
<title>Release 12.19</title> <title>Release 12.19</title>