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:

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.

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.

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.