List of bug fixes going into Beta 2 release.

diff --git a/releases/11/beta/11beta2.md b/releases/11/beta/11beta2.md
index 2e804912337a3bf2e60dcf824883cc5595dd26be..d3bdf64ebab6c836ad6f54837d54d1eefc8ccc56 100644 (file)
--- a/releases/11/beta/11beta2.md
+++ b/releases/11/beta/11beta2.md
@@ -28,6 +28,17 @@ There have been many bug fixes for PostgreSQL 11 reported during the Beta 1 peri
 * Fixes for query parallelism, including preventing a crash by ignoring "parallel append" for parallel unsafe paths in a query plan
 * `pg_upgrade` now uses the "fast ALTER TABLE .. ADD COLUMN" feature with a non-NULL default
 * Add new configure flags introduced in PostgreSQL 11 to the corresponding Windows configure file
+* Fix issue where `COPY FROM .. WITH HEADER` would drop a line after every 4,294,967,296 lines processed
+* Ensure the "B" (bytes) parameter is accepted by all memory-related configuration parameters
+* Several fixes specific to the Windows platform
+* Fix for plpgsql checking statements where it needs to check original write statement before rewrite, could cause crash
+* Several fixes related to VACUUM
+* Fix for `SHOW ALL` to display superuser configuration settings to roles that are allowed to read all settings
+* Several fixes for the JSONB transform in PL/Python and PL/Perl
+* Several additional memory leak fixes
+* Fix for potential replica server crashes where a replica would attempt to read a recycled WAL segment
+* Several fixes for XML support, including using the document node as the context for XMLTABLE Xpath queries as defined in the SQL standard
+* Fix returning accurate results with "variance" and similar aggregate functions when executed using parallel query
 
 This update also contains tzdata release 2018e, with updates for North Korea. The 2018e also reintroduces the negative-DST changes that were originally introduced in 2018a, which affects historical and present timestamps for Ireland (1971-), as well as historical timestamps for Namibia (1994-2017) and the former Czechoslovakia (1946-1947). If your application is storing timestamps with those timezones in the affected date ranges, we ask that you please test to ensure your applications behave as expected.