<!-- doc/src/sgml/release-10.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-10-21">
+ <title>Release 10.21</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2022-05-12</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 10.20.
+ For information about new features in major release 10, see
+ <xref linkend="release-10">.
+ </para>
+
+ <para>
+ The <productname>PostgreSQL</productname> community will stop
+ releasing updates for the 10.X release series in November 2022.
+ Users are encouraged to update to a newer release branch soon.
+ </para>
+
+ <sect2>
+ <title>Migration to Version 10.21</title>
+
+ <para>
+ A dump/restore is not required for those running 10.X.
+ </para>
+
+ <para>
+ However, if you are upgrading from a version earlier than 10.19,
+ see <xref linkend="release-10-19">.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <listitem>
+<!--
+Branch: master [ec62cb0aa] 2022-03-17 18:18:05 -0400
+Branch: REL_14_STABLE [1d072bd20] 2022-03-17 18:18:05 -0400
+Branch: REL_13_STABLE [5e144cc89] 2022-03-17 18:18:05 -0400
+Branch: REL_12_STABLE [1f5ef5ae0] 2022-03-17 18:18:05 -0400
+Branch: REL_11_STABLE [13b54d1e0] 2022-03-17 18:18:05 -0400
+Branch: REL_10_STABLE [205214c8b] 2022-03-17 18:18:05 -0400
+-->
+ <para>
+ Stop using query-provided column aliases for the columns of
+ whole-row variables that refer to plain tables (Tom Lane)
+ </para>
+
+ <para>
+ The column names in tuples produced by a whole-row variable (such
+ as <literal>tbl.*</literal> in contexts other than the top level of
+ a <literal>SELECT</literal> list) are now always those of the
+ associated named composite type, if there is one. We'd previously
+ attempted to make them track any column aliases that had been
+ applied to the <literal>FROM</literal> entry the variable refers to.
+ But that's semantically dubious, because really then the output of
+ the variable is not at all of the composite type it claims to be.
+ Previous attempts to deal with that inconsistency had bad results up
+ to and including storing unreadable data on disk, so just give up on
+ the whole idea.
+ </para>
+
+ <para>
+ In cases where it's important to be able to relabel such columns,
+ a workaround is to introduce an extra level of
+ sub-<literal>SELECT</literal>, so that the whole-row variable is
+ referring to the sub-<literal>SELECT</literal>'s output and not to a
+ plain table. Then the variable is of type <type>record</type>
+ to begin with and there's no issue.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [eafdf9de0] 2022-04-20 18:08:23 -0400
+Branch: REL_14_STABLE [e34632947] 2022-04-20 18:08:24 -0400
+Branch: REL_13_STABLE [8275ba773] 2022-04-20 18:08:15 -0400
+Branch: REL_12_STABLE [33fe55c06] 2022-04-20 18:08:15 -0400
+Branch: REL_11_STABLE [e7adbd282] 2022-04-20 18:08:15 -0400
+Branch: REL_10_STABLE [a1e4782a0] 2022-04-20 18:08:15 -0400
+-->
+ <para>
+ Disallow infinite endpoints in the timestamp variants
+ of <function>generate_series()</function> (Tom Lane)
+ </para>
+
+ <para>
+ Previously, such a call would run until canceled (or
+ out-of-disk-space). The numeric variant already threw an error for
+ an infinite endpoint value, so do likewise for timestamps.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [068739fb4] 2022-03-18 16:01:42 -0400
+Branch: REL_14_STABLE [ae8ec7feb] 2022-03-18 16:01:42 -0400
+Branch: REL_13_STABLE [88ae77588] 2022-03-18 16:01:42 -0400
+Branch: REL_12_STABLE [840729fd1] 2022-03-18 16:01:42 -0400
+Branch: REL_11_STABLE [84f3ecdaa] 2022-03-18 16:01:42 -0400
+Branch: REL_10_STABLE [e6fd4a3da] 2022-03-18 16:01:42 -0400
+-->
+ <para>
+ Fix incorrect output for types <type>timestamptz</type>
+ and <type>timetz</type> in <function>table_to_xmlschema()</function>
+ and allied functions (Renan Soares Lopes)
+ </para>
+
+ <para>
+ The xmlschema output for these types included a malformed regular
+ expression.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [2591ee8ec] 2022-03-21 17:44:29 -0400
+Branch: REL_14_STABLE [48b6035f0] 2022-03-21 17:44:29 -0400
+Branch: REL_13_STABLE [dfefe38fb] 2022-03-21 17:44:29 -0400
+Branch: REL_12_STABLE [69c88e2fb] 2022-03-21 17:44:29 -0400
+Branch: REL_11_STABLE [5de244196] 2022-03-21 17:44:29 -0400
+Branch: REL_10_STABLE [2afa031ac] 2022-03-21 17:44:29 -0400
+-->
+ <para>
+ Fix planner errors for <function>GROUPING()</function> constructs
+ that reference outer query levels (Richard Guo, Tom Lane)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [e5691cc91] 2022-02-11 15:24:02 -0500
+Branch: REL_14_STABLE [277e744ae] 2022-02-11 15:23:52 -0500
+Branch: REL_13_STABLE [0778b24ce] 2022-02-11 15:23:52 -0500
+Branch: REL_12_STABLE [32e801676] 2022-02-11 15:23:52 -0500
+Branch: REL_11_STABLE [14ee565f3] 2022-02-11 15:23:52 -0500
+Branch: REL_10_STABLE [b6f869bee] 2022-02-11 15:23:52 -0500
+-->
+ <para>
+ Fix plan generation for index-only scans on indexes with
+ both returnable and non-returnable columns (Tom Lane)
+ </para>
+
+ <para>
+ The previous coding could try to read non-returnable columns
+ in addition to the returnable ones. This was fairly harmless
+ because it didn't actually do anything with the bogus values,
+ but it fell foul of a recently-added error check that rejected
+ such a plan.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [3f74daa8d] 2022-02-14 04:17:04 +0300
+Branch: REL_14_STABLE [c76665edc] 2022-02-14 03:32:31 +0300
+Branch: REL_13_STABLE [ac2303aa0] 2022-02-14 03:32:34 +0300
+Branch: REL_12_STABLE [7a12a9e3c] 2022-02-14 03:32:39 +0300
+Branch: REL_11_STABLE [0d554775b] 2022-02-14 04:04:19 +0300
+Branch: REL_10_STABLE [2e9033a54] 2022-02-14 04:04:28 +0300
+-->
+ <para>
+ Fix query-lifespan memory leak in an IndexScan node that is
+ performing reordering (Aliaksandr Kalenik)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [344a225cb] 2022-04-19 23:03:59 -0400
+Branch: REL_14_STABLE [08a9e7a8c] 2022-04-19 23:03:59 -0400
+Branch: REL_13_STABLE [f583633bc] 2022-04-19 23:03:59 -0400
+Branch: REL_12_STABLE [481a99811] 2022-04-19 23:03:59 -0400
+Branch: REL_11_STABLE [9130f8cbb] 2022-04-19 23:03:59 -0400
+Branch: REL_10_STABLE [409bcfda6] 2022-04-19 23:03:59 -0400
+-->
+ <para>
+ Fix <command>ALTER FUNCTION</command> to support changing a
+ function's parallelism property and
+ its <literal>SET</literal>-variable list in the same command (Tom
+ Lane)
+ </para>
+
+ <para>
+ The parallelism property change was lost if the same command also
+ updated the function's <literal>SET</literal> clause.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [8ab0ebb9a] 2022-04-20 17:17:43 -0700
+Branch: REL_14_STABLE [e4521841a] 2022-04-20 17:17:41 -0700
+Branch: REL_13_STABLE [1272630a2] 2022-04-20 17:17:39 -0700
+Branch: REL_12_STABLE [5487585e3] 2022-04-20 17:17:37 -0700
+Branch: REL_11_STABLE [adb2d84fc] 2022-04-20 17:17:35 -0700
+Branch: REL_10_STABLE [a903895b3] 2022-04-20 17:17:33 -0700
+-->
+ <para>
+ Fix mis-sorting of table rows when <command>CLUSTER</command>ing
+ using an index whose leading key is an expression (Peter Geoghegan,
+ Thomas Munro)
+ </para>
+
+ <para>
+ The table would be rebuilt with the correct data, but in an order
+ having little to do with the index order.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [46d9bfb0a] 2022-03-16 17:20:24 +1300
+Branch: REL_14_STABLE [26e007939] 2022-03-16 17:20:50 +1300
+Branch: REL_13_STABLE [51e760e5a] 2022-03-16 17:21:19 +1300
+Branch: REL_12_STABLE [c918f07dd] 2022-03-16 17:21:46 +1300
+Branch: REL_11_STABLE [ca522c60a] 2022-03-16 17:38:55 +1300
+Branch: REL_10_STABLE [fe197872c] 2022-03-16 17:41:31 +1300
+-->
+ <para>
+ Fix race condition between <command>DROP TABLESPACE</command> and
+ checkpointing (Nathan Bossart)
+ </para>
+
+ <para>
+ The checkpoint forced by <command>DROP TABLESPACE</command> could
+ sometimes fail to remove all dead files from the tablespace's
+ directory, leading to a bogus <quote>tablespace is not empty</quote>
+ error.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [412ad7a55] 2022-03-24 14:52:28 -0400
+Branch: REL_14_STABLE [bbace5697] 2022-03-24 14:32:48 -0400
+Branch: REL_13_STABLE [1ce14b6b2] 2022-03-24 14:36:06 -0400
+Branch: REL_12_STABLE [3821d66a7] 2022-03-24 14:38:51 -0400
+Branch: REL_11_STABLE [118f1a332] 2022-03-24 14:49:08 -0400
+Branch: REL_10_STABLE [57f618310] 2022-03-24 14:50:06 -0400
+Branch: REL_14_STABLE [10520f434] 2022-04-14 11:10:07 -0400
+Branch: REL_13_STABLE [d18c913b7] 2022-04-14 11:10:11 -0400
+Branch: REL_12_STABLE [68e605b9e] 2022-04-14 11:10:13 -0400
+Branch: REL_11_STABLE [6270ee445] 2022-04-14 11:10:16 -0400
+Branch: REL_10_STABLE [48b398943] 2022-04-14 11:10:18 -0400
+-->
+ <para>
+ Fix possible trouble in crash recovery after
+ a <command>TRUNCATE</command> command that overlaps a checkpoint
+ (Kyotaro Horiguchi, Heikki Linnakangas, Robert Haas)
+ </para>
+
+ <para>
+ <command>TRUNCATE</command> must ensure that the table's disk file
+ is truncated before the checkpoint is allowed to complete.
+ Otherwise, replay starting from that checkpoint might find
+ unexpected data in the supposedly-removed pages, possibly causing
+ replay failure.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [7c38ef2a5] 2022-02-21 08:57:34 -0800
+Branch: REL_14_STABLE [7bbfe5994] 2022-02-21 09:57:05 -0800
+Branch: REL_13_STABLE [c2551483e] 2022-02-21 08:59:30 -0800
+Branch: REL_12_STABLE [0033fc63f] 2022-02-21 08:59:32 -0800
+Branch: REL_11_STABLE [3faa21bb7] 2022-02-21 08:59:34 -0800
+Branch: REL_10_STABLE [cebc54b90] 2022-02-21 08:59:36 -0800
+-->
+ <para>
+ Fix unsafe toast-data accesses during temporary object cleanup
+ (Andres Freund)
+ </para>
+
+ <para>
+ Temporary-object deletion during server process exit could fail
+ with <quote>FATAL: cannot fetch toast data without an active
+ snapshot</quote>. This was usually harmless since the next use of
+ that temporary schema would clean up successfully.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [9d92582ab] 2022-03-23 18:22:10 +0100
+Branch: REL_14_STABLE [caaeb88ff] 2022-03-23 18:22:10 +0100
+Branch: REL_13_STABLE [98eb3e06c] 2022-03-23 18:22:10 +0100
+Branch: REL_12_STABLE [c714ebd0e] 2022-03-23 18:22:10 +0100
+Branch: REL_11_STABLE [199cd7b59] 2022-03-23 18:22:10 +0100
+Branch: REL_10_STABLE [9ade3c09a] 2022-03-23 18:22:10 +0100
+-->
+ <para>
+ Fix <quote>PANIC: xlog flush request is not satisfied</quote>
+ failure during standby promotion when there is a missing WAL
+ continuation record (Sami Imseih)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [8f1537d10] 2022-05-02 18:25:00 -0700
+Branch: REL_14_STABLE [9ab3b2bdb] 2022-05-02 18:25:59 -0700
+Branch: REL_13_STABLE [57c5ad168] 2022-05-02 18:28:10 -0700
+Branch: REL_12_STABLE [edfc03ec9] 2022-05-02 18:29:52 -0700
+Branch: REL_11_STABLE [9cda785b4] 2022-05-02 18:30:15 -0700
+Branch: REL_10_STABLE [cbc47ad7e] 2022-05-02 18:30:38 -0700
+Branch: REL_14_STABLE [f74496dd6] 2022-05-02 18:26:09 -0700
+Branch: REL_13_STABLE [0446d3bf3] 2022-05-02 18:29:35 -0700
+Branch: REL_12_STABLE [a5ede1391] 2022-05-02 18:29:52 -0700
+Branch: REL_11_STABLE [25d5494e2] 2022-05-02 18:30:15 -0700
+Branch: REL_10_STABLE [b1f35a36e] 2022-05-02 18:30:38 -0700
+Branch: REL_14_STABLE [5ab8e8014] 2022-05-02 18:09:42 -0700
+Branch: REL_13_STABLE [90abe1e17] 2022-05-02 18:09:43 -0700
+Branch: REL_12_STABLE [5c8b14a71] 2022-05-02 18:09:43 -0700
+Branch: REL_11_STABLE [2adb8debe] 2022-05-02 18:09:44 -0700
+Branch: REL_10_STABLE [e8a0cf9b2] 2022-05-02 18:09:44 -0700
+-->
+ <para>
+ Fix possibility of self-deadlock in hot standby conflict handling
+ (Andres Freund)
+ </para>
+
+ <para>
+ With unlucky timing, the WAL-applying process could get stuck
+ while waiting for some other process to release a buffer lock.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [dd4ab6fd6] 2022-04-19 08:49:49 +0530
+Branch: REL_14_STABLE [c9dea58e2] 2022-04-19 08:54:37 +0530
+Branch: REL_13_STABLE [82d4a17a1] 2022-04-19 09:08:05 +0530
+Branch: REL_12_STABLE [59348fbde] 2022-04-19 09:18:44 +0530
+Branch: REL_11_STABLE [a90de822e] 2022-04-19 09:29:34 +0530
+Branch: REL_10_STABLE [be46985be] 2022-04-19 09:38:25 +0530
+-->
+ <para>
+ Ensure that logical replication apply workers can be restarted even
+ when we're up against
+ the <varname>max_sync_workers_per_subscription</varname> limit
+ (Amit Kapila)
+ </para>
+
+ <para>
+ Faulty coding of the limit check caused a restarted worker to exit
+ immediately, leaving fewer workers than there should be.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [5e01001ff] 2022-02-14 08:55:58 +0530
+Branch: REL_14_STABLE [04645bbca] 2022-02-14 08:07:46 +0530
+Branch: REL_13_STABLE [caa231be9] 2022-02-14 08:24:44 +0530
+Branch: REL_12_STABLE [ce349cf17] 2022-02-14 08:27:56 +0530
+Branch: REL_11_STABLE [1cd5802ac] 2022-02-14 08:37:23 +0530
+Branch: REL_10_STABLE [b5e060473] 2022-02-14 08:45:54 +0530
+-->
+ <para>
+ Include unchanged replica identity key columns in the WAL log for an
+ update, if they are stored out-of-line (Dilip Kumar, Amit Kapila)
+ </para>
+
+ <para>
+ Otherwise subscribers cannot see the values and will fail to
+ replicate the update.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: REL_12_STABLE [e16db75dd] 2022-02-15 12:21:28 -0500
+Branch: REL_11_STABLE [efae4401c] 2022-02-15 12:21:28 -0500
+Branch: REL_10_STABLE [17a8c4c3a] 2022-02-15 12:21:28 -0500
+-->
+ <para>
+ Improve logical replication subscriber's error message for an
+ unsupported relation kind (Tom Lane)
+ </para>
+
+ <para>
+ v13 and later servers support publishing partitioned tables. Older
+ server versions cannot handle subscribing to such a table, and they
+ gave a very misleading error message: <quote>table XYZ not found on
+ publisher</quote>. Arrange to deliver a more on-point message.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [638300fef] 2022-02-25 17:40:43 -0500
+Branch: REL_14_STABLE [ac910bb23] 2022-02-25 17:40:43 -0500
+Branch: REL_13_STABLE [9b2d762a2] 2022-02-25 17:40:44 -0500
+Branch: REL_12_STABLE [0f7b62f29] 2022-02-25 17:40:45 -0500
+Branch: REL_11_STABLE [31befa6be] 2022-02-25 17:40:45 -0500
+Branch: REL_10_STABLE [4936747c4] 2022-02-25 17:40:21 -0500
+-->
+ <para>
+ Disallow execution of SPI functions during PL/Perl function
+ compilation (Tom Lane)
+ </para>
+
+ <para>
+ Perl can be convinced to execute user-defined code during compilation
+ of a PL/Perl function. However, it's not okay for such code to try
+ to invoke SQL operations via SPI. That results in a crash, and if
+ it didn't crash it would be a security hazard, because we really
+ don't want code execution during function validation. Put in a
+ check to give a friendlier error message instead.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [a59c79564] 2022-02-28 14:12:52 -0500
+Branch: master [50f03473e] 2022-03-02 11:29:11 -0500
+Branch: REL_14_STABLE [2a1f84636] 2022-03-02 11:57:02 -0500
+Branch: REL_13_STABLE [6599d8f12] 2022-03-02 11:57:02 -0500
+Branch: REL_12_STABLE [72918ea86] 2022-03-02 11:57:02 -0500
+Branch: REL_11_STABLE [5bb3d91ea] 2022-03-02 11:57:02 -0500
+Branch: REL_10_STABLE [9050999ef] 2022-03-02 11:57:02 -0500
+Branch: master [878e64d0f] 2022-03-31 11:24:26 -0400
+Branch: REL_14_STABLE [402279afe] 2022-03-31 11:24:26 -0400
+Branch: REL_13_STABLE [fb1d7f451] 2022-03-31 11:24:26 -0400
+Branch: REL_12_STABLE [fcaf7d725] 2022-03-31 11:24:26 -0400
+Branch: REL_11_STABLE [143043191] 2022-03-31 11:24:26 -0400
+Branch: REL_10_STABLE [a6bd1f0ee] 2022-03-31 11:24:26 -0400
+-->
+ <para>
+ Make <application>libpq</application> accept root-owned SSL private
+ key files (David Steele)
+ </para>
+
+ <para>
+ This change synchronizes <application>libpq</application>'s rules
+ for safe ownership and permissions of SSL key files with the rules
+ the server has used since release 9.6. Namely, in addition to the
+ current rules, allow the case where the key file is owned by root
+ and has permissions <literal>rw-r-----</literal> or less. This is
+ helpful for system-wide management of key files.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [a745b9365] 2022-02-10 16:49:39 -0500
+Branch: REL_14_STABLE [1e8c5cf7c] 2022-02-10 16:49:39 -0500
+Branch: REL_13_STABLE [d0e1fd958] 2022-02-10 16:49:39 -0500
+Branch: REL_12_STABLE [61c20a5ea] 2022-02-10 16:49:39 -0500
+Branch: REL_11_STABLE [69cc15c31] 2022-02-10 16:49:39 -0500
+Branch: REL_10_STABLE [34523933b] 2022-02-10 16:49:39 -0500
+-->
+ <para>
+ Make <application>pg_ctl</application> recheck postmaster aliveness
+ while waiting for stop/restart/promote actions (Tom Lane)
+ </para>
+
+ <para>
+ <application>pg_ctl</application> would verify that the postmaster
+ is alive as a side-effect of sending the stop or promote signal, but
+ then it just naively waited to see the on-disk state change. If the
+ postmaster died uncleanly without having removed its PID file or
+ updated the control file, <application>pg_ctl</application> would
+ wait until timeout. Instead make it recheck every so often that the
+ postmaster process is still there.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [cd4868a57] 2022-04-14 15:08:03 +0900
+Branch: REL_14_STABLE [df6bbe73b] 2022-04-14 15:09:26 +0900
+Branch: REL_13_STABLE [2275d044d] 2022-04-14 15:09:36 +0900
+Branch: REL_12_STABLE [5378d55cb] 2022-04-14 15:09:39 +0900
+Branch: REL_11_STABLE [79fed072b] 2022-04-14 15:09:42 +0900
+Branch: REL_10_STABLE [12d32b7bc] 2022-04-14 15:09:46 +0900
+-->
+ <para>
+ Ensure that <filename>contrib/pageinspect</filename> functions cope
+ with all-zero pages (Michael Paquier)
+ </para>
+
+ <para>
+ This is a legitimate edge case, but the module was mostly unprepared
+ for it. Arrange to return nulls, or no rows, as appropriate; that
+ seems more useful than raising an error.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [291e517a4] 2022-03-27 17:53:40 +0900
+Branch: REL_14_STABLE [27d384441] 2022-03-27 17:53:51 +0900
+Branch: REL_13_STABLE [3d4d6dee0] 2022-03-27 17:53:55 +0900
+Branch: REL_12_STABLE [5ca2aa2f2] 2022-03-27 17:53:59 +0900
+Branch: REL_11_STABLE [1a2fdf86a] 2022-03-27 17:54:03 +0900
+Branch: REL_10_STABLE [ab80b0fbb] 2022-03-27 17:54:08 +0900
+Branch: master [076f4d953] 2022-03-16 11:19:39 +0900
+Branch: REL_14_STABLE [b61e6214c] 2022-03-16 11:20:47 +0900
+Branch: REL_13_STABLE [d3a9b83c3] 2022-03-16 11:20:51 +0900
+Branch: REL_12_STABLE [af8a8eb54] 2022-03-16 11:20:54 +0900
+Branch: REL_11_STABLE [2389ee8dd] 2022-03-16 11:20:57 +0900
+Branch: REL_10_STABLE [c42b88932] 2022-03-16 11:21:00 +0900
+Branch: master [4477dcb20] 2022-03-16 12:29:39 +0900
+Branch: REL_14_STABLE [dc5b3bdae] 2022-03-16 12:29:47 +0900
+Branch: REL_13_STABLE [028a3c6b1] 2022-03-16 12:29:55 +0900
+Branch: REL_12_STABLE [5cb770210] 2022-03-16 12:29:59 +0900
+Branch: REL_11_STABLE [09c97746d] 2022-03-16 12:30:02 +0900
+Branch: REL_10_STABLE [07e343513] 2022-03-16 12:30:07 +0900
+-->
+ <para>
+ In <filename>contrib/pageinspect</filename>, add defenses against
+ incorrect page <quote>special space</quote> contents, tighten checks
+ for correct page size, and add some missing checks that an index is
+ of the expected type (Michael Paquier, Justin Pryzby, Julien
+ Rouhaud)
+ </para>
+
+ <para>
+ These changes make it less likely that the module will crash on bad
+ data.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [f3dd9fe1d] 2022-03-31 14:29:48 -0400
+Branch: REL_14_STABLE [9f9489aa2] 2022-03-31 14:29:24 -0400
+Branch: REL_13_STABLE [79df1d20c] 2022-03-31 14:29:24 -0400
+Branch: REL_12_STABLE [989d3e4a2] 2022-03-31 14:29:24 -0400
+Branch: REL_11_STABLE [b9eb0412f] 2022-03-31 14:29:24 -0400
+Branch: REL_10_STABLE [728fc0f9a] 2022-03-31 14:29:24 -0400
+-->
+ <para>
+ In <filename>contrib/postgres_fdw</filename>, verify
+ that <literal>ORDER BY</literal> clauses are safe to ship before
+ requesting a remotely-ordered query, and include
+ a <literal>USING</literal> clause if necessary (Ronan Dunklau)
+ </para>
+
+ <para>
+ This fix prevents situations where the remote server might sort in a
+ different order than we intend. While sometimes that would be only
+ cosmetic, it could produce thoroughly wrong results if the remote
+ data is used as input for a locally-performed merge join.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [46ab07ffd] 2022-03-03 18:13:24 -0500
+Branch: REL_14_STABLE [b0bc196e5] 2022-03-03 18:13:24 -0500
+Branch: REL_13_STABLE [1a027e6b7] 2022-03-03 18:13:24 -0500
+Branch: REL_12_STABLE [f727b6ea8] 2022-03-03 18:13:24 -0500
+Branch: REL_11_STABLE [f2087e26e] 2022-03-03 18:13:24 -0500
+Branch: REL_10_STABLE [cfbe87bd6] 2022-03-03 18:13:24 -0500
+Branch: master [0fbdfaf79] 2022-03-03 19:03:17 -0500
+Branch: REL_14_STABLE [5c9d17e94] 2022-03-03 19:03:35 -0500
+Branch: REL_13_STABLE [97031f440] 2022-03-03 19:03:42 -0500
+Branch: REL_12_STABLE [4b0696b36] 2022-03-03 19:03:46 -0500
+Branch: REL_11_STABLE [566e1c04d] 2022-03-03 19:03:50 -0500
+Branch: REL_10_STABLE [18c04d157] 2022-03-03 19:03:55 -0500
+Branch: master [3ac7d0241] 2022-03-23 13:05:59 -0700
+Branch: REL_14_STABLE [81045e1e1] 2022-03-23 13:18:02 -0700
+Branch: REL_13_STABLE [c0f99bb52] 2022-03-23 13:18:00 -0700
+Branch: REL_12_STABLE [61a007fee] 2022-03-23 13:17:59 -0700
+Branch: master [1c6bb380e] 2022-03-23 13:05:25 -0700
+Branch: REL_14_STABLE [89a94c24a] 2022-03-23 13:13:18 -0700
+Branch: REL_13_STABLE [8014c61eb] 2022-03-23 13:13:20 -0700
+Branch: REL_12_STABLE [c5b60a68c] 2022-03-23 13:13:33 -0700
+Branch: REL_11_STABLE [2121d5809] 2022-03-23 13:13:40 -0700
+Branch: REL_10_STABLE [5f4615b9d] 2022-03-23 13:13:49 -0700
+Branch: master [e71c76fca] 2022-03-23 12:43:14 -0700
+Branch: REL_14_STABLE [e52e9bd57] 2022-03-23 12:43:41 -0700
+Branch: REL_13_STABLE [7c163aa93] 2022-03-23 12:43:40 -0700
+Branch: REL_12_STABLE [6a767bc2e] 2022-03-23 12:43:38 -0700
+Branch: REL_11_STABLE [a77dddb42] 2022-03-23 12:43:36 -0700
+Branch: REL_10_STABLE [2a9193726] 2022-03-23 12:43:33 -0700
+-->
+ <para>
+ Clean up assorted failures under <productname>clang</productname>'s
+ <literal>-fsanitize=undefined</literal> checks (Tom Lane, Andres
+ Freund, Zhihong Yu)
+ </para>
+
+ <para>
+ Most of these changes are just for pro-forma compliance with the
+ letter of the C and POSIX standards, and are unlikely to have any
+ effect on production builds.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [d5c2a91e5] 2022-02-08 19:25:56 -0500
+Branch: REL_14_STABLE [e327291e4] 2022-02-08 19:26:09 -0500
+Branch: REL_13_STABLE [5ea3b99de] 2022-02-08 19:26:17 -0500
+Branch: REL_12_STABLE [eba0f095c] 2022-02-08 19:26:22 -0500
+Branch: REL_11_STABLE [3a6e3a890] 2022-02-08 19:26:26 -0500
+Branch: REL_10_STABLE [1a8b6f055] 2022-02-08 19:26:30 -0500
+-->
+ <para>
+ Fix PL/Perl so it builds on C compilers that don't support statements
+ nested within expressions (Tom Lane)
+ </para>
+
+ <para>
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [097786fbb] 2022-03-22 08:22:02 -0700
+Branch: REL_14_STABLE [2d608c960] 2022-03-22 08:28:51 -0700
+Branch: REL_13_STABLE [f183e23cc] 2022-03-22 08:28:52 -0700
+Branch: REL_12_STABLE [4553b960f] 2022-03-22 08:28:53 -0700
+Branch: REL_11_STABLE [cd1951ba0] 2022-03-22 08:28:54 -0700
+Branch: REL_10_STABLE [083031aa9] 2022-03-22 08:28:55 -0700
+-->
+ <para>
+ Fix possible build failure of <application>pg_dumpall</application>
+ on Windows, when not using MSVC to build (Andres Freund)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [ea09a75e1] 2022-02-10 13:44:05 -0500
+Branch: REL_14_STABLE [92f60f536] 2022-02-10 13:51:19 -0500
+Branch: REL_13_STABLE [eec7c640f] 2022-02-10 13:51:40 -0500
+Branch: REL_12_STABLE [64dd64807] 2022-02-10 13:51:49 -0500
+Branch: REL_11_STABLE [e2d104e19] 2022-02-10 13:51:59 -0500
+Branch: REL_10_STABLE [a5eef80c2] 2022-02-10 13:52:05 -0500
+Branch: REL9_6_STABLE [622ab6a34] 2022-02-10 13:52:37 -0500
+Branch: REL9_5_STABLE [3a5034b5e] 2022-02-10 13:53:56 -0500
+Branch: REL9_4_STABLE [c76164ea0] 2022-02-10 13:56:55 -0500
+-->
+ <para>
+ In Windows builds, use <application>gendef</application> instead
+ of <application>pexports</application> to build DEF files (Andrew
+ Dunstan)
+ </para>
+
+ <para>
+ This adapts the build process to work on recent MSys tool chains.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [b787c554c] 2022-04-25 15:47:55 -0400
+Branch: REL_14_STABLE [71f394667] 2022-04-25 15:49:35 -0400
+Branch: REL_13_STABLE [d9cede2c3] 2022-04-25 15:50:01 -0400
+Branch: REL_12_STABLE [01f2bc5af] 2022-04-25 15:50:07 -0400
+Branch: REL_11_STABLE [b90ce0dd7] 2022-04-25 15:51:27 -0400
+Branch: REL_10_STABLE [58887d58c] 2022-04-25 15:51:58 -0400
+-->
+ <para>
+ Prevent extra expansion of shell wildcard patterns in programs built
+ under MinGW (Andrew Dunstan)
+ </para>
+
+ <para>
+ For some reason the C library provided by MinGW will expand shell
+ wildcard characters in a program's command-line arguments by
+ default. This is confusing, not least because it doesn't happen
+ under MSVC, so turn it off.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Branch: master [ab3479bf5] 2022-05-05 14:54:53 -0400
+Branch: REL_14_STABLE [77ee14ed9] 2022-05-05 14:55:03 -0400
+Branch: REL_13_STABLE [e9735d1af] 2022-05-05 14:55:10 -0400
+Branch: REL_12_STABLE [2bb9f7501] 2022-05-05 14:55:17 -0400
+Branch: REL_11_STABLE [da72ff09b] 2022-05-05 14:55:22 -0400
+Branch: REL_10_STABLE [bc334ec9f] 2022-05-05 14:55:30 -0400
+-->
+ <para>
+ Update time zone data files to <application>tzdata</application>
+ release 2022a for DST law changes in Palestine, plus historical
+ corrections for Chile and Ukraine.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </sect2>
+ </sect1>
+
<sect1 id="release-10-20">
<title>Release 10.20</title>
projects / postgresql.git / commitdiff