open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Release notes for 15.2, 14.7, 13.10, 12.14, 11.19.

Browse Source
pull/158/head
Tom Lane 3 years ago
parent c7b31ecc27
commit 70192be7bd
1 changed files with 827 additions and 0 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 827
      doc/src/sgml/release-13.sgml

827
doc/src/sgml/release-13.sgml
Unescape View File

@ -1,6 +1,833 @@
<!-- doc/src/sgml/release-13.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-13-10">
<title>Release 13.10</title>
<formalpara>
<title>Release date:</title>
<para>2023-02-09</para>
</formalpara>
<para>
This release contains a variety of fixes from 13.9.
For information about new features in major release 13, see
<xref linkend="release-13"/>.
</para>
<sect2>
<title>Migration to Version 13.10</title>
<para>
A dump/restore is not required for those running 13.X.
</para>
<para>
However, if you are upgrading from a version earlier than 13.7,
see <xref linkend="release-13-7"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3f7836ff6] 2023-01-05 14:12:17 -0500
Branch: REL_15_STABLE [3706cc97a] 2023-01-05 14:12:17 -0500
Branch: REL_14_STABLE [8cd190e13] 2023-01-05 14:12:17 -0500
Branch: REL_13_STABLE [ad38e2f89] 2023-01-05 14:12:17 -0500
Branch: master [3f244d020] 2023-01-15 13:14:52 -0500
Branch: REL_15_STABLE [a8f7687a0] 2023-01-15 14:06:46 -0500
Branch: REL_14_STABLE [a8b88c26f] 2023-01-15 14:06:46 -0500
Branch: REL_13_STABLE [787db4be9] 2023-01-15 14:06:46 -0500
-->
<para>
Fix calculation of which <literal>GENERATED</literal> columns need
to be updated in child tables during an <command>UPDATE</command> on
a partitioned table or inheritance tree (Amit Langote, Tom Lane)
</para>
<para>
This fixes failure to update <literal>GENERATED</literal> columns
that do not exist in the parent table, or that have different
dependencies than are in the parent column's generation expression.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c9f7f9264] 2023-01-21 13:10:29 -0500
Branch: REL_15_STABLE [9e4288ce6] 2023-01-21 13:10:29 -0500
Branch: REL_14_STABLE [70ec756b0] 2023-01-21 13:10:29 -0500
Branch: REL_13_STABLE [72d611109] 2023-01-21 13:10:29 -0500
Branch: REL_12_STABLE [a5f3f2fce] 2023-01-21 13:10:30 -0500
Branch: REL_11_STABLE [6c122edde] 2023-01-21 13:10:30 -0500
-->
<para>
Allow <literal>REPLICA IDENTITY</literal>
to be set on an index that's not (yet) valid (Tom Lane)
</para>
<para>
When <application>pg_dump</application> dumps a partitioned index
that's marked <literal>REPLICA IDENTITY</literal>, it generates a
command sequence that applies <literal>REPLICA IDENTITY</literal>
before the partitioned index has been marked valid, causing restore
to fail. There seems no very good reason to prohibit doing it in
that order, so allow it. The marking will have no effect anyway
until the index becomes valid.
</para>
</listitem>
<listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [2605643a3] 2022-12-03 12:11:33 +0000
Branch: REL_15_STABLE [c67204db6] 2022-12-03 12:14:36 +0000
Branch: REL_14_STABLE [2c7ed9f75] 2022-12-03 12:16:07 +0000
Branch: REL_13_STABLE [3bed88123] 2022-12-03 12:17:47 +0000
Branch: REL_12_STABLE [33f600f04] 2022-12-03 12:18:58 +0000
Branch: REL_11_STABLE [30f9b03a0] 2022-12-03 12:20:02 +0000
-->
<para>
Fix handling of <literal>DEFAULT</literal> markers in rules that
perform an <command>INSERT</command> from a
multi-row <literal>VALUES</literal> list (Dean Rasheed)
</para>
<para>
In some cases a <literal>DEFAULT</literal> marker would not get
replaced with the proper default-value expression, leading to
an <quote>unrecognized node type</quote> error.
</para>
</listitem>
<listitem>
<!--
Author: Alexander Korotkov <akorotkov@postgresql.org>
Branch: master [3161ae86c] 2023-01-12 18:16:34 +0300
Branch: REL_15_STABLE [4dc3f94fa] 2023-01-12 18:17:43 +0300
Branch: REL_14_STABLE [0d9221f1d] 2023-01-12 18:18:04 +0300
Branch: REL_13_STABLE [2ff3ac3b5] 2023-01-12 18:18:31 +0300
Branch: REL_12_STABLE [9e24e4781] 2023-01-12 18:19:19 +0300
-->
<para>
Reject uses of undefined variables in <type>jsonpath</type>
existence checks (Alexander Korotkov, David G. Johnston)
</para>
<para>
While <type>jsonpath</type> match operators threw an error for an
undefined variable in the path pattern, the existence operators
silently treated it as a match.
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [ffcf6f4cf] 2023-01-26 14:52:19 +1300
Branch: REL_15_STABLE [d9f5345bf] 2023-01-26 14:53:37 +1300
Branch: REL_14_STABLE [2f65b8468] 2023-01-26 14:54:17 +1300
Branch: REL_13_STABLE [1a5afe007] 2023-01-26 14:54:39 +1300
Branch: REL_12_STABLE [b55303792] 2023-01-26 14:55:03 +1300
Branch: REL_11_STABLE [d95dcc9ab] 2023-01-26 14:55:37 +1300
-->
<para>
Fix edge-case data corruption in parallel hash joins (Dmitry Astapov)
</para>
<para>
If the final chunk of a large tuple being written out to a temporary
file was exactly 32760 bytes, it would be corrupted due to a
fencepost bug. The query would typically fail later with
corrupted-data symptoms.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [7e8a80d1f] 2023-01-19 13:13:05 +0900
Branch: REL_15_STABLE [49e3a5e71] 2023-01-19 13:13:27 +0900
Branch: REL_14_STABLE [2e21e2857] 2023-01-19 13:13:28 +0900
Branch: REL_13_STABLE [fed4e92f3] 2023-01-19 13:13:30 +0900
Branch: REL_12_STABLE [162a48287] 2023-01-19 13:13:32 +0900
Branch: REL_11_STABLE [0c2f34af7] 2023-01-19 13:13:34 +0900
-->
<para>
Honor non-default settings
of <varname>checkpoint_completion_target</varname>
(Bharath Rupireddy)
</para>
<para>
Internal state was not updated after a change
in <varname>checkpoint_completion_target</varname>, possibly
resulting in performing checkpoint I/O faster or slower than
desired, especially if that setting was changed on-the-fly.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [44e9e3426] 2023-01-19 12:23:20 -0500
Branch: REL_15_STABLE [abe203304] 2023-01-19 12:23:20 -0500
Branch: REL_14_STABLE [103450724] 2023-01-19 12:23:20 -0500
Branch: REL_13_STABLE [1b9a0b96a] 2023-01-19 12:23:20 -0500
Branch: REL_12_STABLE [87591db19] 2023-01-19 12:23:20 -0500
Branch: REL_11_STABLE [0a269527f] 2023-01-19 12:23:20 -0500
-->
<para>
Log the correct ending timestamp
in <varname>recovery_target_xid</varname> mode (Tom Lane)
</para>
<para>
When ending recovery based on the <varname>recovery_target_xid</varname>
setting with <varname>recovery_target_inclusive</varname>
= <literal>off</literal>, we printed an incorrect timestamp (always
2000-01-01) in the <quote>recovery stopping before
... transaction</quote> log message.
</para>
</listitem>
<listitem>
<!--
Author: Peter Eisentraut <peter@eisentraut.org>
Branch: master [1561612e3] 2023-01-16 09:44:04 +0100
Branch: REL_15_STABLE [ac01fa647] 2023-01-16 09:45:03 +0100
Branch: REL_14_STABLE [f463335e1] 2023-01-16 09:48:09 +0100
Branch: REL_13_STABLE [cf74b6ead] 2023-01-16 09:54:15 +0100
-->
<para>
Improve error reporting for some buffered file read failures
(Peter Eisentraut)
</para>
<para>
Correctly report a short read, giving the numbers of bytes desired
and actually read, instead of reporting an irrelevant error code.
Most places got this right already, but some recently-written
replication logic did not.
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_13_STABLE [72b6098be] 2023-01-11 09:56:14 +0900
Branch: REL_12_STABLE [c0ee6943c] 2023-01-11 09:56:18 +0900
-->
<para>
Prevent <quote>wrong tuple length</quote> failure
at the end of <command>VACUUM</command> (Ashwin Agrawal, Junfeng Yang)
</para>
<para>
This occurred if <command>VACUUM</command> needed to update the
current database's <structfield>datfrozenxid</structfield> value and
the database has so many granted privileges that
its <structfield>datacl</structfield> value has been pushed
out-of-line.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [20432f873] 2022-12-13 14:23:58 -0500
Branch: REL_15_STABLE [18431ee6f] 2022-12-13 14:23:59 -0500
Branch: REL_14_STABLE [ae47f8a96] 2022-12-13 14:23:59 -0500
Branch: REL_13_STABLE [942cc240f] 2022-12-13 14:23:59 -0500
Branch: REL_12_STABLE [1cca4a75f] 2022-12-13 14:23:59 -0500
Branch: REL_11_STABLE [f48aa5df4] 2022-12-13 14:23:59 -0500
-->
<para>
In extended query protocol, avoid an immediate commit
after <command>ANALYZE</command> if we're running a pipeline
(Tom Lane)
</para>
<para>
If there's not been an explicit <command>BEGIN
TRANSACTION</command>, <command>ANALYZE</command> would take it on
itself to commit, which should not happen within a pipelined series
of commands.
</para>
</listitem>
<listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [e52daaabf] 2023-01-21 06:08:00 -0800
Branch: REL_15_STABLE [b152bb7b2] 2023-01-21 06:08:03 -0800
Branch: REL_14_STABLE [6900aea67] 2023-01-21 06:08:04 -0800
Branch: REL_13_STABLE [a9bccffe5] 2023-01-21 06:08:04 -0800
Branch: REL_12_STABLE [e75b5c855] 2023-01-21 06:08:04 -0800
Branch: REL_11_STABLE [8f70de7e0] 2023-01-21 06:08:05 -0800
-->
<para>
Reject cancel request packets having the wrong length
(Andrey Borodin)
</para>
<para>
The server would process a cancel request even if its length word
was too small. This led to reading beyond the end of the allocated
buffer. In theory that could cause a segfault, but it seems quite
unlikely to happen in practice, since the buffer would have to be
very close to the end of memory. The more likely outcome was a bogus
log message about wrong backend PID or cancel code. Complain about
the wrong length, instead.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5beb7881f] 2022-12-22 10:35:02 -0500
Branch: REL_15_STABLE [1a3daa5bb] 2022-12-22 10:35:02 -0500
Branch: REL_14_STABLE [97431d673] 2022-12-22 10:35:02 -0500
Branch: REL_13_STABLE [4fceb454f] 2022-12-22 10:35:03 -0500
Branch: REL_12_STABLE [d572003f7] 2022-12-22 10:35:03 -0500
Branch: REL_11_STABLE [8cd700cc5] 2022-12-22 10:35:03 -0500
-->
<para>
Add recursion and looping defenses in subquery pullup (Tom Lane)
</para>
<para>
A contrived query can result in deep recursion and unreasonable
amounts of time spent trying to flatten subqueries. A proper fix
for that seems unduly invasive for a back-patch, but we can at least
add stack depth checks and an interrupt check to allow the query to
be cancelled.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [fe12f2f8f] 2022-12-04 13:17:18 -0500
Branch: REL_15_STABLE [bf8fd64ff] 2022-12-04 13:17:18 -0500
Branch: REL_14_STABLE [ec3daeec3] 2022-12-04 13:17:18 -0500
Branch: REL_13_STABLE [4ebca555c] 2022-12-04 13:17:18 -0500
Branch: REL_12_STABLE [1ff549e84] 2022-12-04 13:17:18 -0500
Branch: REL_11_STABLE [2df073313] 2022-12-04 13:17:18 -0500
-->
<para>
Fix partitionwise-join code to tolerate failure to produce a plan for
each partition (Tom Lane)
</para>
<para>
This could result in <quote>could not devise a query plan for the
given query</quote> errors.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [9c6ad5eaa] 2022-11-22 14:40:20 -0500
Branch: REL_15_STABLE [2debceed2] 2022-11-22 14:40:44 -0500
Branch: REL_14_STABLE [bd06fe4de] 2022-11-22 14:40:45 -0500
Branch: REL_13_STABLE [6e639267a] 2022-11-22 14:40:45 -0500
Branch: REL_12_STABLE [ec10b6139] 2022-11-22 14:40:45 -0500
Branch: REL_11_STABLE [b96a096db] 2022-11-22 14:40:46 -0500
-->
<para>
Limit the amount of cleanup work done
by <function>get_actual_variable_range</function> (Simon Riggs)
</para>
<para>
Planner runs occurring just after deletion of a large number of
tuples appearing at the end of an index could expend significant
amounts of work setting the <quote>killed</quote> bits for those
index entries. Limit the amount of work done in any one query by
giving up on this process after examining 100 heap pages. All the
cleanup will still happen eventually, but without so large a
performance hiccup.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [5644d6f90] 2022-11-21 17:07:29 -0500
Branch: REL_15_STABLE [0353db996] 2022-11-21 17:07:07 -0500
Branch: REL_14_STABLE [1b9c04b13] 2022-11-21 17:07:07 -0500
Branch: REL_13_STABLE [74670688f] 2022-11-21 17:07:07 -0500
Branch: REL_12_STABLE [1aed4c4fd] 2022-11-21 17:07:07 -0500
Branch: REL_11_STABLE [c0eed8891] 2022-11-21 17:07:07 -0500
-->
<para>
Ensure that execution of full-text-search queries can be cancelled
while they are performing phrase matches (Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [edf12e7bb] 2022-12-01 11:49:15 -0800
Branch: REL_15_STABLE [9377b4f30] 2022-12-01 11:55:59 -0800
Branch: REL_14_STABLE [47e1224d5] 2022-12-01 11:53:53 -0800
Branch: REL_13_STABLE [a844052b5] 2022-12-01 11:52:06 -0800
Branch: REL_12_STABLE [f98c4fb1d] 2022-12-01 11:49:43 -0800
-->
<para>
Fix memory leak in hashing strings with nondeterministic collations
(Jeff Davis)
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [bc54ef4ec] 2023-01-23 18:27:42 -0800
Branch: REL_15_STABLE [704a330a9] 2023-01-23 18:27:45 -0800
Branch: REL_14_STABLE [0a796b8b3] 2023-01-23 18:27:48 -0800
Branch: REL_13_STABLE [c5864805b] 2023-01-23 18:27:51 -0800
Branch: REL_12_STABLE [92fc12787] 2023-01-23 18:27:55 -0800
Branch: REL_11_STABLE [243373159] 2023-01-23 18:27:58 -0800
-->
<para>
Clean up the <application>libpq</application> connection object
after a failed replication connection attempt (Andres Freund)
</para>
<para>
The previous coding leaked the connection object. In background
code paths that's pretty harmless because the calling process will
give up and exit. But in commands such as <command>CREATE
SUBSCRIPTION</command>, such a failure resulted in a small
session-lifespan memory leak.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8242752f9] 2022-11-29 15:43:17 -0500
Branch: REL_15_STABLE [55fa993d7] 2022-11-29 15:43:17 -0500
Branch: REL_14_STABLE [06998eab1] 2022-11-29 15:43:17 -0500
Branch: REL_13_STABLE [6e8ad1152] 2022-11-29 15:43:17 -0500
Branch: REL_12_STABLE [c4a153d77] 2022-11-29 15:43:17 -0500
Branch: REL_11_STABLE [a6c9e1db2] 2022-11-29 15:43:17 -0500
-->
<para>
In hot-standby servers, reduce processing effort for tracking XIDs
known to be active on the primary (Simon Riggs, Michail Nikolaev)
</para>
<para>
Insufficiently-aggressive cleanup of the KnownAssignedXids array
could lead to poor performance, particularly
when <varname>max_connections</varname> is set to a large value on
the standby.
</para>
</listitem>
<listitem>
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [0557e1770] 2022-11-22 10:56:07 +0100
Branch: REL_15_STABLE [1ad033df1] 2022-11-22 10:56:07 +0100
Branch: REL_14_STABLE [1b3ed7571] 2022-11-22 10:56:07 +0100
Branch: REL_13_STABLE [36eeb37cd] 2022-11-22 10:56:07 +0100
-->
<para>
Ignore invalidated logical-replication slots while determining
oldest catalog xmin (Sirisha Chamarthi)
</para>
<para>
A replication slot could prevent cleanup of dead tuples in the
system catalogs even after it becomes invalidated due to
exceeding <varname>max_slot_wal_keep_size</varname>. Thus, failure
of a replication consumer could lead to indefinitely-large catalog
bloat.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: REL_15_STABLE [898ef41bf] 2022-11-25 09:38:03 +0530
Branch: REL_14_STABLE [9f2cc1a73] 2022-11-25 09:25:50 +0530
Branch: REL_13_STABLE [4ec157c15] 2022-11-25 09:15:31 +0530
Branch: REL_12_STABLE [aa9d916f6] 2022-11-25 09:00:15 +0530
Branch: REL_11_STABLE [9b788aafd] 2022-11-25 08:56:54 +0530
-->
<para>
Fix uninitialized-memory usage in logical decoding (Masahiko Sawada)
</para>
<para>
In certain cases, resumption of logical decoding could try to re-use
XID data that had already been freed, leading to unpredictable
behavior.
</para>
</listitem>
<listitem>
<!--
Author: Amit Kapila <akapila@postgresql.org>
Branch: master [e848be60b] 2022-11-14 10:43:33 +0530
Branch: REL_15_STABLE [e49e19181] 2022-11-14 10:32:47 +0530
Branch: REL_14_STABLE [9693f1900] 2022-11-14 10:22:28 +0530
Branch: REL_13_STABLE [20c223336] 2022-11-14 10:11:10 +0530
Branch: REL_12_STABLE [4dccccb37] 2022-11-14 10:01:14 +0530
Branch: REL_11_STABLE [1703033f8] 2022-11-14 09:52:06 +0530
-->
<para>
Avoid rare <quote>failed to acquire cleanup lock</quote> panic
during WAL replay of hash-index page split operations (Robert Haas)
</para>
</listitem>
<listitem>
<!--
Author: Jeff Davis <jdavis@postgresql.org>
Branch: master [d6a3dbe14] 2022-11-11 12:38:29 -0800
Branch: REL_15_STABLE [7bf713dd2] 2022-11-11 12:46:11 -0800
Branch: REL_14_STABLE [f893af496] 2022-11-11 12:46:22 -0800
Branch: REL_13_STABLE [58a45bb1d] 2022-11-11 12:46:34 -0800
Branch: REL_12_STABLE [7dd39e9e8] 2022-11-11 12:46:44 -0800
Branch: REL_11_STABLE [5eaf3e375] 2022-11-11 12:46:52 -0800
-->
<para>
Advance a heap page's LSN when setting its all-visible bit during
WAL replay (Jeff Davis)
</para>
<para>
Failure to do this left the page possibly different on standby
servers than the primary, and violated some other expectations about
when the LSN changes. This seems only a theoretical hazard so
far as <productname>PostgreSQL</productname> itself is concerned,
but it could upset third-party tools.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [32d5a4974] 2022-11-17 16:54:30 -0500
Branch: REL_13_STABLE [9a299cf7c] 2022-11-17 16:54:30 -0500
Branch: REL_12_STABLE [e21856fd6] 2022-11-17 16:54:31 -0500
Branch: REL_11_STABLE [d4acf2eb9] 2022-11-17 16:54:31 -0500
-->
<para>
Prevent unsafe usage of a relation cache
entry's <structfield>rd_smgr</structfield> pointer (Amul Sul)
</para>
<para>
Remove various assumptions that <structfield>rd_smgr</structfield>
would stay valid over a series of operations, by wrapping all uses
of it in a function that will recompute it if needed. This prevents
bugs occurring when an unexpected cache flush occurs partway through
such a series.
</para>
</listitem>
<listitem>
<!--
Author: Thomas Munro <tmunro@postgresql.org>
Branch: master [f1821b58f] 2023-01-13 11:02:12 +1300
Branch: REL_15_STABLE [8a98523a5] 2023-01-13 11:02:00 +1300
Branch: REL_14_STABLE [547e60b83] 2023-01-13 10:57:29 +1300
Branch: REL_13_STABLE [c159b0383] 2023-01-13 10:54:49 +1300
Branch: REL_12_STABLE [bf388ab82] 2023-01-13 10:54:34 +1300
Branch: REL_11_STABLE [1b40710a8] 2023-01-13 10:54:20 +1300
-->
<para>
Fix latent buffer-overrun problem in <literal>WaitEventSet</literal>
logic (Thomas Munro)
</para>
<para>
The <function>epoll</function>-based
and <function>kqueue</function>-based implementations could ask the
kernel for too many events if the size of their internal buffer was
different from the size of the caller's output buffer. That case is
not known to occur in released <productname>PostgreSQL</productname>
versions, but this error is a hazard for external modules and future
bug fixes.
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [8c954168c] 2022-11-19 12:22:04 -0800
Branch: REL_15_STABLE [a0d35ebcc] 2022-11-19 12:33:11 -0800
Branch: REL_14_STABLE [fc4154286] 2022-11-19 12:33:14 -0800
Branch: REL_13_STABLE [c13667b51] 2022-11-19 12:36:33 -0800
Branch: REL_12_STABLE [4cbcb7ed8] 2022-11-19 12:36:48 -0800
Branch: REL_11_STABLE [140c80372] 2022-11-19 12:36:52 -0800
-->
<para>
Avoid nominally-undefined behavior when accessing shared memory in
32-bit builds (Andres Freund)
</para>
<para>
clang's undefined-behavior sanitizer complained about use of a
pointer that was less aligned than it should be. It's very unlikely
that this would cause a problem in non-debug builds, but it's worth
fixing for testing purposes.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [51dfaa0b0] 2022-11-29 10:52:44 -0500
Branch: REL_15_STABLE [556c0b913] 2022-11-29 10:52:44 -0500
Branch: REL_14_STABLE [0224646be] 2022-11-29 10:52:44 -0500
Branch: REL_13_STABLE [aca695fb6] 2022-11-29 10:52:44 -0500
Branch: REL_12_STABLE [bb8d48cb9] 2022-11-29 10:52:44 -0500
-->
<para>
Remove faulty assertion in useless-RESULT-RTE optimization logic
(Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [2fcf685f6] 2022-12-23 10:04:18 +0900
Branch: REL_15_STABLE [e3897a3a4] 2022-12-23 10:04:30 +0900
Branch: REL_14_STABLE [7ad458e06] 2022-12-23 10:04:33 +0900
Branch: REL_13_STABLE [4dbe72d61] 2022-12-23 10:04:34 +0900
Branch: REL_12_STABLE [7445869e1] 2022-12-23 10:04:36 +0900
Branch: REL_11_STABLE [df6fea51f] 2022-12-23 10:04:37 +0900
-->
<para>
Fix copy-and-paste errors in cache-lookup-failure messages for ACL
checks (Justin Pryzby)
</para>
<para>
In principle these errors should never be reached. But if they are,
some of them reported the wrong type of object.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_14_STABLE [55f30e6c7] 2022-11-19 11:40:30 -0500
Branch: REL_13_STABLE [e46e986ba] 2022-11-19 11:40:30 -0500
Branch: REL_12_STABLE [344b78492] 2022-11-19 11:40:30 -0500
Branch: REL_11_STABLE [b1f106420] 2022-11-19 11:40:30 -0500
Branch: REL_14_STABLE [03ac48549] 2022-11-19 12:00:27 -0500
Branch: REL_13_STABLE [a5b26aaaf] 2022-11-19 12:00:27 -0500
Branch: REL_12_STABLE [1ed6f1b91] 2022-11-19 12:00:27 -0500
Branch: REL_11_STABLE [b7333e826] 2022-11-19 12:00:27 -0500
-->
<para>
In <application>pg_dump</application>,
avoid calling unsafe server functions before we have locks on the
tables to be examined (Tom Lane, Gilles Darold)
</para>
<para>
<application>pg_dump</application> uses certain server functions
that can fail if examining a table that gets dropped concurrently.
Avoid this type of failure by ensuring that we obtain access share
lock before inquiring too deeply into a table's properties, and that
we don't apply such functions to tables we don't intend to dump at
all.
</para>
</listitem>
<listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [e7a59094b] 2023-01-06 11:18:44 +0000
Branch: REL_15_STABLE [2daf4664c] 2023-01-06 11:16:53 +0000
Branch: REL_14_STABLE [48599a18d] 2023-01-06 11:15:22 +0000
Branch: REL_13_STABLE [2ad4abedf] 2023-01-06 11:13:34 +0000
Branch: REL_12_STABLE [274185d11] 2023-01-06 11:11:51 +0000
Branch: REL_11_STABLE [c54b88870] 2023-01-06 11:09:56 +0000
-->
<para>
Fix tab completion of <command>ALTER
FUNCTION/PROCEDURE/ROUTINE</command> ... <command>SET
SCHEMA</command> (Dean Rasheed)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [701c881f7] 2022-12-21 17:51:50 -0500
Branch: REL_15_STABLE [b87037b37] 2022-12-21 17:51:50 -0500
Branch: REL_14_STABLE [f489b480f] 2022-12-21 17:51:50 -0500
Branch: REL_13_STABLE [d35f1d485] 2022-12-21 17:51:50 -0500
Branch: REL_12_STABLE [c8314d62a] 2022-12-21 17:51:50 -0500
Branch: REL_11_STABLE [0ff4056b8] 2022-12-21 17:51:50 -0500
-->
<para>
Fix <filename>contrib/seg</filename> to not crash or print garbage
if an input number has more than 127 digits (Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: REL_13_STABLE [c304c069d] 2022-11-09 09:39:53 +0900
Branch: REL_12_STABLE [edb4ef48d] 2022-11-09 09:39:55 +0900
Branch: REL_11_STABLE [91723759e] 2022-11-09 09:39:57 +0900
Branch: REL_10_STABLE [8f5d4ee6c] 2022-11-09 09:39:58 +0900
Branch: REL9_6_STABLE [b2b988110] 2022-11-09 09:40:01 +0900
Branch: REL9_5_STABLE [40064e103] 2022-11-09 09:40:02 +0900
Branch: REL9_4_STABLE [0f5812df6] 2022-11-09 09:40:05 +0900
Branch: REL9_3_STABLE [a5171b880] 2022-11-09 09:40:06 +0900
Branch: REL9_2_STABLE [c58c0770a] 2022-11-09 09:40:09 +0900
-->
<para>
In <filename>contrib/sepgsql</filename>, avoid deprecation warnings
with recent <application>libselinux</application> (Michael Paquier)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_15_STABLE [576506303] 2022-11-10 10:23:49 -0500
Branch: REL_14_STABLE [06dca17ad] 2022-11-10 10:23:49 -0500
Branch: REL_13_STABLE [0942acb73] 2022-11-10 10:23:49 -0500
Branch: REL_12_STABLE [cf0f465c0] 2022-11-10 10:23:49 -0500
-->
<para>
Fix build on Microsoft Visual Studio 2013 (Tom Lane)
</para>
<para>
A previous patch supposed that all platforms of interest
have <function>snprintf()</function>, but MSVC 2013 isn't quite
there yet. Revert to using <function>sprintf()</function> on that
platform.
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [341f4e002] 2022-11-25 15:28:38 -0500
Branch: REL_15_STABLE [fed54fc9a] 2022-11-25 15:37:33 -0500
Branch: REL_14_STABLE [f76191fd9] 2022-11-25 15:37:33 -0500
Branch: REL_13_STABLE [9fe5cff14] 2022-11-25 15:37:33 -0500
Branch: REL_12_STABLE [171c7fffa] 2022-11-25 15:37:34 -0500
Branch: REL_11_STABLE [ae7c51213] 2022-11-25 15:37:34 -0500
-->
<para>
Fix compile failure in building PL/Perl with MSVC when using
Strawberry Perl (Andrew Dunstan)
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [ccc59a83c] 2022-11-27 09:03:22 -0500
Branch: REL_15_STABLE [b5d8fd418] 2022-11-27 09:18:14 -0500
Branch: REL_14_STABLE [f3f70b8de] 2022-11-27 09:18:20 -0500
Branch: REL_13_STABLE [68d89d80c] 2022-11-27 09:18:32 -0500
Branch: REL_12_STABLE [85565cbca] 2022-11-27 09:18:40 -0500
Branch: REL_11_STABLE [724dd5649] 2022-11-27 09:18:46 -0500
-->
<para>
Fix mismatch of PL/Perl built with MSVC versus a Perl library built
with gcc (Andrew Dunstan)
</para>
<para>
Such combinations could previously fail with <quote>loadable library
and perl binaries are mismatched</quote> errors.
</para>
</listitem>
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [388e80132] 2022-12-29 12:47:29 -0800
Branch: REL_15_STABLE [c6e75e4c2] 2023-01-02 15:49:33 -0800
Branch: REL_14_STABLE [7b5dec760] 2023-01-02 15:50:00 -0800
Branch: REL_13_STABLE [ce073d014] 2023-01-02 15:50:33 -0800
Branch: REL_12_STABLE [f0e13802f] 2023-01-02 15:51:03 -0800
Branch: REL_11_STABLE [99f8bc335] 2023-01-02 15:51:05 -0800
-->
<para>
Suppress compiler warnings from Perl's header files (Andres Freund)
</para>
<para>
Our preferred compiler options provoke warnings about constructs
appearing in recent versions of Perl's header files. When using
<application>gcc</application>, we can suppress these warnings with
a pragma.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL_15_STABLE [9a40a0311] 2023-01-20 11:58:12 -0500
Branch: REL_14_STABLE [21c058648] 2023-01-20 11:58:12 -0500
Branch: REL_13_STABLE [c78f109b8] 2023-01-20 11:58:12 -0500
Branch: REL_12_STABLE [6d066d56b] 2023-01-20 11:58:12 -0500
Branch: REL_11_STABLE [b69e9dfab] 2023-01-20 11:58:12 -0500
-->
<para>
Fix <application>pg_waldump</application> to build on compilers that
don't discard unused static-inline functions (Tom Lane)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [758f44bc3] 2023-01-31 17:36:55 -0500
Branch: REL_15_STABLE [65f0d9d27] 2023-01-31 17:37:06 -0500
Branch: REL_14_STABLE [7e6154779] 2023-01-31 17:37:14 -0500
Branch: REL_13_STABLE [20d9da107] 2023-01-31 17:37:22 -0500
Branch: REL_12_STABLE [2c95d8776] 2023-01-31 17:37:28 -0500
Branch: REL_11_STABLE [7ddc428ef] 2023-01-31 17:37:34 -0500
-->
<para>
Update time zone data files to <application>tzdata</application>
release 2022g for DST law changes in Greenland and Mexico,
plus historical corrections for northern Canada, Colombia, and
Singapore.
</para>
<para>
Notably, a new timezone America/Ciudad_Juarez has been split off
from America/Ojinaga.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-13-9">
<title>Release 13.9</title>

Write Preview
Loading…
Cancel
Save