First-draft release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22.

diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index a96cd8dce2da764b35a9f16e7596ea688d238d62..c6300751551773f4aaf4593b693a814217704f0b 100644 (file)
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -1,6 +1,188 @@
 
 
 
+ 
+  Release 9.4.4
+
+  
+  Release Date
+  2015-06-12
+  
+
+  
+   This release contains a small number of fixes from 9.4.3.
+   For information about new features in the 9.4 major release, see
+   .
+  
+
+  
+   Migration to Version 9.4.4
+
+   
+    A dump/restore is not required for those running 9.4.X.
+   
+
+   
+    However, if you are upgrading an installation that was previously
+    upgraded using a pg_upgrade version between 9.3.0 and
+    9.3.4 inclusive, see the first changelog entry below.
+   
+
+   
+    Also, if you are upgrading from a version earlier than 9.4.2,
+    see .
+   
+  
+
+  
+   Changes
+
+   
+
+
+
+    
+     
+      Fix possible failure to recover from an inconsistent database state
+      (Robert Haas)
+     
+
+     
+      Recent PostgreSQL releases introduced mechanisms to
+      protect against multixact wraparound, but some of that code did not
+      account for the possibility that it would need to run during crash
+      recovery, when the database may not be in a consistent state.  This
+      could result in failure to restart after a crash, or failure to start
+      up a secondary server.  The lingering effects of a previously-fixed
+      bug in pg_upgrade could also cause such a failure, in
+      installations that had used pg_upgrade versions
+      between 9.3.0 and 9.3.4.
+     
+
+     
+      The  pg_upgrade bug in question was that it would
+      set oldestMultiXid to 1 in pg_control even
+      if the true value should be higher.  With the fixes introduced in
+      this release, such a situation will result in immediate emergency
+      autovacuuming until a correct oldestMultiXid value can
+      be determined.  Users can avoid that by doing manual
+      vacuuming before upgrading to this release.
+      In detail:
+
+      
+       
+        
+         Check whether pg_controldata reports Latest
+         checkpoint's oldestMultiXid to be 1.  If not, there's nothing
+         to do.
+        
+       
+       
+        
+         Look in PGDATA/pg_multixact/offsets to see if there's a
+         file named 0000.  If there is, there's nothing to do.
+        
+       
+       
+        
+         Otherwise, for each table that has
+         pg_class.relminmxid equal to 1,
+         VACUUM that table with
+         both 
+         and  set to
+         zero.  (You can use the vacuum cost delay parameters described
+         in  to reduce
+         the performance consequences for concurrent sessions.)  You must
+         use PostgreSQL 9.3.5 or later to perform this step.
+        
+       
+      
+     
+    
+
+
+
+    
+     
+      Fix rare failure to invalidate relation cache init file (Tom Lane)
+     
+
+     
+      With just the wrong timing of concurrent activity, a VACUUM
+      FULL on a system catalog might fail to update the init file
+      that's used to avoid cache-loading work for new sessions.  This would
+      result in later sessions being unable to access that catalog at all.
+      This is a very ancient bug, but it's so hard to trigger that no
+      reproducible case had been seen until recently.
+     
+    
+
+
+
+    
+     
+      Avoid deadlock between incoming sessions and CREATE/DROP
+      DATABASE (Tom Lane)
+     
+
+     
+      A new session starting in a database that is the target of
+      a DROP DATABASE command, or is the template for
+      a CREATE DATABASE command, could cause the command to wait
+      for five seconds and then fail, even if the new session would have
+      exited before that.
+     
+    
+
+
+
+    
+     
+      Improve planner's cost estimates for semi-joins and anti-joins with
+      inner indexscans (Tom Lane, Tomas Vondra)
+     
+
+     
+      This type of plan is quite cheap when all the join clauses are used
+      as index scan conditions, even if the inner scan would nominally
+      fetch many rows, because the executor will stop after obtaining one
+      row.  The planner only partially accounted for that effect, and would
+      therefore overestimate the cost, leading it to possibly choose some
+      other much less efficient plan type.
+     
+    
+
+   
+
+  
+ 
+
  
   Release 9.4.3