From b94085920b016e64ee40a0f6c50199889565cc56 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 9 Jun 2015 14:33:43 -0400 Subject: [PATCH] Release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22. --- doc/src/sgml/release-9.0.sgml | 74 +++++++++++++++++ doc/src/sgml/release-9.1.sgml | 68 ++++++++++++++++ doc/src/sgml/release-9.2.sgml | 68 ++++++++++++++++ doc/src/sgml/release-9.3.sgml | 149 ++++++++++++++++++++++++++++++++++ doc/src/sgml/release-9.4.sgml | 9 +- 5 files changed, 363 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml index 80cd1c43cd..736b6dda63 100644 --- a/doc/src/sgml/release-9.0.sgml +++ b/doc/src/sgml/release-9.0.sgml @@ -1,6 +1,80 @@ + + Release 9.0.22 + + + Release Date + 2015-06-12 + + + + This release contains a small number of fixes from 9.0.21. + For information about new features in the 9.0 major release, see + . + + + + The PostgreSQL community will stop releasing updates + for the 9.0.X release series in September 2015. + Users are encouraged to update to a newer release branch soon. + + + + Migration to Version 9.0.22 + + + A dump/restore is not required for those running 9.0.X. + + + + However, if you are upgrading from a version earlier than 9.0.18, + see . + + + + + + Changes + + + + + + 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. + + + + + + + + Release 9.0.21 diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml index 8306cfab03..a97ec57276 100644 --- a/doc/src/sgml/release-9.1.sgml +++ b/doc/src/sgml/release-9.1.sgml @@ -1,6 +1,74 @@ + + Release 9.1.18 + + + Release Date + 2015-06-12 + + + + This release contains a small number of fixes from 9.1.17. + For information about new features in the 9.1 major release, see + . + + + + Migration to Version 9.1.18 + + + A dump/restore is not required for those running 9.1.X. + + + + However, if you are upgrading from a version earlier than 9.1.16, + see . + + + + + + Changes + + + + + + 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. + + + + + + + + Release 9.1.17 diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml index ef4ce98e53..d91328e7c1 100644 --- a/doc/src/sgml/release-9.2.sgml +++ b/doc/src/sgml/release-9.2.sgml @@ -1,6 +1,74 @@ + + Release 9.2.13 + + + Release Date + 2015-06-12 + + + + This release contains a small number of fixes from 9.2.12. + For information about new features in the 9.2 major release, see + . + + + + Migration to Version 9.2.13 + + + A dump/restore is not required for those running 9.2.X. + + + + However, if you are upgrading from a version earlier than 9.2.11, + see . + + + + + + Changes + + + + + + 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. + + + + + + + + Release 9.2.12 diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml index 8f1bc7e147..6aafbd7307 100644 --- a/doc/src/sgml/release-9.3.sgml +++ b/doc/src/sgml/release-9.3.sgml @@ -1,6 +1,155 @@ + + Release 9.3.9 + + + Release Date + 2015-06-12 + + + + This release contains a small number of fixes from 9.3.8. + For information about new features in the 9.3 major release, see + . + + + + Migration to Version 9.3.9 + + + A dump/restore is not required for those running 9.3.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.3.7, + 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. If that would pose a hardship, users can avoid it 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.3.8 diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml index c630075155..0b63efc7a3 100644 --- a/doc/src/sgml/release-9.4.sgml +++ b/doc/src/sgml/release-9.4.sgml @@ -65,13 +65,13 @@ Branch: REL9_3_STABLE [2a9b01928] 2015-06-05 09:34:15 -0400 - The pg_upgrade bug in question was that it would + 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. + be determined. If that would pose a hardship, users can avoid it by + doing manual vacuuming before upgrading to this release. In detail: @@ -97,8 +97,7 @@ Branch: REL9_3_STABLE [2a9b01928] 2015-06-05 09:34:15 -0400 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. + the performance consequences for concurrent sessions.) -- 2.40.0