diff options
| -rw-r--r-- | doc/src/sgml/release-11.sgml | 802 |
1 files changed, 802 insertions, 0 deletions
diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml index d6bf8c5fe02..f72df507214 100644 --- a/doc/src/sgml/release-11.sgml +++ b/doc/src/sgml/release-11.sgml @@ -1,6 +1,808 @@ <!-- doc/src/sgml/release-11.sgml --> <!-- See header comment in release.sgml about typical markup --> + <sect1 id="release-11-16"> + <title>Release 11.16</title> + + <formalpara> + <title>Release date:</title> + <para>2022-05-12</para> + </formalpara> + + <para> + This release contains a variety of fixes from 11.15. + For information about new features in major release 11, see + <xref linkend="release-11"/>. + </para> + + <sect2> + <title>Migration to Version 11.16</title> + + <para> + A dump/restore is not required for those running 11.X. + </para> + + <para> + However, if you are upgrading from a version earlier than 11.14, + see <xref linkend="release-11-14"/>. + </para> + </sect2> + + <sect2> + <title>Changes</title> + + <itemizedlist> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Alexander Korotkov <akorotkov@postgresql.org> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Peter Geoghegan <pg@bowt.ie> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master [7b6ec8653] 2022-03-21 12:22:13 -0400 +Branch: REL_14_STABLE [05ccf974c] 2022-03-21 12:22:13 -0400 +Branch: REL_13_STABLE [2241e5ced] 2022-03-21 12:22:13 -0400 +Branch: REL_12_STABLE [d8d378d51] 2022-03-21 12:22:13 -0400 +Branch: REL_11_STABLE [b8ae17fd9] 2022-03-21 12:22:13 -0400 +--> + <para> + Fix risk of deadlock failures while dropping a partitioned index + (Jimmy Yih, Gaurab Dey, Tom Lane) + </para> + + <para> + Ensure that the required table and index locks are taken in the + standard order (parents before children, tables before indexes). + The previous coding for <command>DROP INDEX</command> did it + differently, and so could deadlock against concurrent queries taking + these locks in the standard order. + </para> + </listitem> + + <listitem> +<!-- +Author: Thomas Munro <tmunro@postgresql.org> +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> +<!-- +Author: Robert Haas <rhaas@postgresql.org> +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 +Author: Robert Haas <rhaas@postgresql.org> +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> +<!-- +Author: Andres Freund <andres@anarazel.de> +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> +<!-- +Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +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> +<!-- +Author: Andres Freund <andres@anarazel.de> +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 +Author: Andres Freund <andres@anarazel.de> +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 +Author: Andres Freund <andres@anarazel.de> +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> +<!-- +Author: Amit Kapila <akapila@postgresql.org> +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> +<!-- +Author: Amit Kapila <akapila@postgresql.org> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master [a59c79564] 2022-02-28 14:12:52 -0500 +Author: Tom Lane <tgl@sss.pgh.pa.us> +Branch: master [50f03473e] 2022-03-02 11:29:11 -0500 +Author: Tom Lane <tgl@sss.pgh.pa.us> +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 +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Andres Freund <andres@anarazel.de> +Branch: master [cd83cb953] 2022-02-25 10:30:05 -0800 +Branch: REL_14_STABLE [9ff7fd906] 2022-02-25 10:31:16 -0800 +Branch: REL_13_STABLE [0b1020a96] 2022-02-25 10:32:38 -0800 +Branch: REL_12_STABLE [5407241a8] 2022-02-25 10:34:38 -0800 +Branch: REL_11_STABLE [51c341656] 2022-02-25 10:40:32 -0800 +Author: Andres Freund <andres@anarazel.de> +Branch: master [264d28492] 2022-03-27 18:13:50 -0700 +Branch: REL_14_STABLE [6839aa7a6] 2022-03-27 18:15:10 -0700 +Branch: REL_13_STABLE [344d89abf] 2022-03-27 18:15:14 -0700 +Branch: REL_12_STABLE [5ebd262dc] 2022-03-27 18:15:15 -0700 +Branch: REL_11_STABLE [7d935bdf7] 2022-03-27 18:15:17 -0700 +--> + <para> + Fix error handling in <application>pg_waldump</application> (Kyotaro + Horiguchi, Andres Freund) + </para> + + <para> + While trying to read a WAL file to determine the WAL segment size, + <application>pg_waldump</application> would report an incorrect + error for the case of a too-short file. In addition, the file name + reported in this and related error messages could be garbage. + </para> + </listitem> + + <listitem> +<!-- +Author: Michael Paquier <michael@paquier.xyz> +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> +<!-- +Author: Michael Paquier <michael@paquier.xyz> +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 +Author: Michael Paquier <michael@paquier.xyz> +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 +Author: Michael Paquier <michael@paquier.xyz> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Thomas Munro <tmunro@postgresql.org> +Branch: master [e6a760020] 2021-09-27 10:53:20 +1300 +Author: Thomas Munro <tmunro@postgresql.org> +Branch: master [807fee1a3] 2022-02-04 16:16:10 +1300 +Author: Thomas Munro <tmunro@postgresql.org> +Branch: master [a56e7b660] 2022-03-16 10:30:55 +1300 +Author: Thomas Munro <tmunro@postgresql.org> +Branch: REL_14_STABLE [d9f7ad54e] 2022-03-16 11:42:00 +1300 +Branch: REL_13_STABLE [5610411ac] 2022-03-16 11:41:13 +1300 +Branch: REL_12_STABLE [45a469eb2] 2022-03-16 11:40:43 +1300 +Branch: REL_11_STABLE [986d24042] 2022-03-16 11:35:00 +1300 +--> + <para> + Update <acronym>JIT</acronym> code to work with LLVM 14 + (Thomas Munro) + </para> + </listitem> + + <listitem> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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 +Author: Tom Lane <tgl@sss.pgh.pa.us> +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 +Author: Andres Freund <andres@anarazel.de> +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 +Author: Andres Freund <andres@anarazel.de> +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 +Author: Andres Freund <andres@anarazel.de> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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> +<!-- +Author: Andres Freund <andres@anarazel.de> +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> +<!-- +Author: Andrew Dunstan <andrew@dunslane.net> +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> +<!-- +Author: Andrew Dunstan <andrew@dunslane.net> +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> +<!-- +Author: Tom Lane <tgl@sss.pgh.pa.us> +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-11-15"> <title>Release 11.15</title> |