<!-- doc/src/sgml/release-11.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-11-19">
+ <title>Release 11.19</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2023-02-09</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 11.18.
+ For information about new features in major release 11, see
+ <xref linkend="release-11"/>.
+ </para>
+
+ <para>
+ The <productname>PostgreSQL</productname> community will stop
+ releasing updates for the 11.X release series in November 2023.
+ Users are encouraged to update to a newer release branch soon.
+ </para>
+
+ <sect2>
+ <title>Migration to Version 11.19</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 [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: 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: 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: 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: 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: 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: 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-11-18">
<title>Release 11.18</title>
projects / thirdparty / postgresql.git / commitdiff
