A dump/restore is not required for those running 7.4.X.
However, it might be advisable as the easiest method of
incorporating fixes for two errors that have been found in the
initial contents of 7.4.X system catalogs. A dump/initdb/reload
sequence using 7.4.2's initdb will automatically correct these
problems.

The more severe of the two errors is that data type
anyarray has the wrong alignment label;
this is a problem because the pg_statistic system catalog uses anyarray columns. The mislabeling can cause planner
misestimations and even crashes when planning queries that
involve WHERE clauses on
double-aligned columns (such as float8
and timestamp). It is strongly
recommended that all installations repair this error, either by
initdb or by following the manual repair procedure given
below.

The lesser error is that the system view pg_settings ought to be marked as having
public update access, to allow UPDATE
pg_settings to be used as a substitute for SET. This can also be fixed either by initdb or
manually, but it is not necessary to fix unless you want to use
UPDATE pg_settings.

If you wish not to do an initdb, the following procedure
will work for fixing pg_statistic.
As the database superuser, do:

-- clear out old data in pg_statistic:
DELETE FROM pg_statistic;
VACUUM pg_statistic;
-- this should update 1 row:
UPDATE pg_type SET typalign = 'd' WHERE oid = 2277;
-- this should update 6 rows:
UPDATE pg_attribute SET attalign = 'd' WHERE atttypid = 2277;
--
-- At this point you MUST start a fresh backend to avoid a crash!
--
-- repopulate pg_statistic:
ANALYZE;

This can be done in a live database, but beware that all
backends running in the altered database must be restarted
before it is safe to repopulate pg_statistic.

To repair the pg_settings error,
simply do:

GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;

The above procedures must be carried out in each database of an installation,
including template1, and ideally
including template0 as well. If you do
not fix the template databases then any subsequently created
databases will contain the same errors. template1 can be fixed in the same way as any
other database, but fixing template0
requires additional steps. First, from any database issue: