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 Section E.58.
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 Section E.56.
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.
see if there's a file named
0000. If there is, there's
nothing to do.
Otherwise, for each table that has
relminmxid equal to 1,
VACUUM that table with
vacuum_multixact_freeze_table_age set to zero.
(You can use the vacuum cost delay parameters
described in Section 19.4.4
to reduce the performance consequences for
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
A new session starting in a database that is the
target of a
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.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.