A dump/restore is not required for those running 7.3.X.
However, it is one possible way of handling a significant
security problem that has been found in the initial contents of
7.3.X system catalogs. A dump/initdb/reload sequence using
7.3.10's initdb will automatically correct this problem.

The security problem is that the built-in character set
encoding conversion functions can be invoked from SQL commands
by unprivileged users, but the functions were not designed for
such use and are not secure against malicious choices of
arguments. The fix involves changing the declared parameter
list of these functions so that they can no longer be invoked
from SQL commands. (This does not affect their normal use by
the encoding conversion machinery.) It is strongly recommended
that all installations repair this error, either by initdb or
by following the manual repair procedure given below. The error
at least allows unprivileged database users to crash their
server process, and might allow unprivileged users to gain the
privileges of a database superuser.

If you wish not to do an initdb, perform the following
procedure instead. As the database superuser, do:

The above procedure 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 error. template1 can be fixed in the same way as any
other database, but fixing template0
requires additional steps. First, from any database issue:

Repair ancient race condition that allowed a transaction
to be seen as committed for some purposes (eg SELECT FOR
UPDATE) slightly sooner than for other purposes

This is an extremely serious bug since it could lead to
apparent data inconsistencies being briefly visible to
applications.

Repair race condition between relation extension and
VACUUM

This could theoretically have caused loss of a page's
worth of freshly-inserted data, although the scenario seems
of very low probability. There are no known cases of it
having caused more than an Assert failure.

Fix comparisons of TIME WITH TIME
ZONE values

The comparison code was wrong in the case where the
--enable-integer-datetimes
configuration switch had been used. NOTE: if you have an
index on a TIME WITH TIME ZONE
column, it will need to be REINDEXed after installing this update,
because the fix corrects the sort order of column
values.

Fix EXTRACT(EPOCH) for
TIME WITH TIME ZONE values

Fix mis-display of negative fractional seconds in
INTERVAL values

This error only occurred when the --enable-integer-datetimes configuration
switch had been used.