+
+
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
+
+
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
+
+
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
+
+
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
projects / postgresql.git / commitdiff