Release date: 2005-05-09
This release contains a variety of fixes from 7.3.9, including several security-related issues.
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:
BEGIN; UPDATE pg_proc SET proargtypes = 'internal'::regtype WHERE pronamespace = 11 AND pronargs = 5 AND proargtypes = 'cstring'::regtype; -- The command should report having updated 90 rows; -- if not, rollback and investigate instead of committing! COMMIT;
The above procedure must be carried out in each database of an installation,
template1, and ideally
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:
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
Next connect to
perform the above repair procedure. Finally, do:
-- re-freeze template0: VACUUM FREEZE; -- and protect it against future alterations: UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
Change encoding function signature to prevent misuse
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
The comparison code was wrong in the case where the
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
TIME WITH TIME ZONE values
Fix mis-display of negative fractional seconds in
This error only occurred when the
switch had been used.
Additional buffer overrun checks in plpgsql (Neil)
Fix pg_dump to dump trigger names containing
% correctly (Neil)
to_char(interval) from dumping core for
newer OpenSSL builds (Marko Kreen)
Still more 64-bit fixes for
Prevent incorrect optimization of functions returning
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.