Release Notes
+
+
Release 8.0.3
+
+
+
Release date
+ 2005-05-05
+
+
+ This release contains a variety of fixes from 8.0.2, including several
+ security-related issues.
+
+
+
+
Migration to version 8.0.3
+
+ A dump/restore is not required for those running 8.0.X. However,
+ it is one possible way of handling two significant security problems
+ that have been found in the initial contents of 8.0.X system
+ catalogs. A dump/initdb/reload sequence using 8.0.3's initdb will
+ automatically correct these problems.
+
+
+ The larger 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.)
+
+
+ The lesser problem is that the contrib/tsearch2 module
+ creates several functions that are misdeclared to return
+ internal when they do not accept internal arguments.
+ This breaks type safety for all functions using internal
+ arguments.
+
+
+ It is strongly recommended that all installations repair these errors,
+ either by initdb or by following the manual repair procedure given
+ below. The errors at least allow unprivileged database users to crash
+ their server process, and may allow unprivileged users to gain the
+ privileges of a database superuser.
+
+
+ If you wish not to do an initdb, perform the same manual repair
+ procedures shown in the 7.4.8 release
+ notes.
+
+
+
+
+
Changes
+
+
+
Change encoding function signature to prevent+misuse
+
Change contrib/tsearch2 to avoid unsafe use of+INTERNAL function results
+
Guard against incorrect second parameter to+record_out
+
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.
+
+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.
+
+
Fix pg_dump to dump trigger names containing %+correctly (Neil)
+
Still more 64-bit fixes for+contrib/intagg
+
Prevent incorrect optimization of functions returning+RECORD
+
Prevent crash on COALESCE(NULL,NULL)+
Fix Borland makefile for libpq+
Fix contrib/btree_gist for timetz type+(Teodor)
+
Make pg_ctl check the PID found in+postmaster.pid to see if it is still a live
+process
+
Fix pg_dump/pg_restore problems caused+by addition of dump timestamps
+
Fix interaction between materializing holdable cursors and+firing deferred triggers during transaction commit
+
Fix memory leak in SQL functions returning pass-by-reference+data types
+
+
+
+
+
Release 8.0.2
+
+
+
+
+
Release 7.4.8
+
+
+
Release date
+ 2005-05-05
+
+
+ This release contains a variety of fixes from 7.4.7, including several
+ security-related issues.
+
+
+
+
Migration to version 7.4.8
+
+ A dump/restore is not required for those running 7.4.X. However,
+ it is one possible way of handling two significant security problems
+ that have been found in the initial contents of 7.4.X system
+ catalogs. A dump/initdb/reload sequence using 7.4.8's initdb will
+ automatically correct these problems.
+
+
+ The larger 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.)
+
+
+ The lesser problem is that the contrib/tsearch2 module
+ creates several functions that are misdeclared to return
+ internal when they do not accept internal arguments.
+ This breaks type safety for all functions using internal
+ arguments.
+
+
+ It is strongly recommended that all installations repair these errors,
+ either by initdb or by following the manual repair procedures given
+ below. The errors at least allow unprivileged database users to crash
+ their server process, and may allow unprivileged users to gain the
+ privileges of a database superuser.
+
+
+ If you wish not to do an initdb, perform the following procedures instead.
+ As the database superuser, do:
+
+BEGIN;
+UPDATE pg_proc SET proargtypes[3] = 'internal'::regtype
+WHERE pronamespace = 11 AND pronargs = 5
+ AND proargtypes[2] = 'cstring'::regtype;
+-- The command should report having updated 90 rows;
+-- if not, rollback and investigate instead of committing!
+COMMIT;
+
+
+ Next, if you have installed contrib/tsearch2, do
+
+BEGIN;
+UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
+WHERE oid IN (
+ 'dex_init(text)'::regprocedure,
+ 'snb_en_init(text)'::regprocedure,
+ 'snb_ru_init(text)'::regprocedure,
+ 'spell_init(text)'::regprocedure,
+ 'syn_init(text)'::regprocedure
+);
+-- The command should report having updated 5 rows;
+-- if not, rollback and investigate instead of committing!
+COMMIT;
+
+
+ If this command fails with a message like function
+ "dex_init(text)" does not exist, then either tsearch2
+ is not installed in this database, or you already did the update.
+
+
+ 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
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+
+ Next connect to template0 and perform the above repair
+ procedures. Finally, do
+-- re-freeze template0:
+VACUUM FREEZE;
+-- and protect it against future alterations:
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+
+
+
+
+
Changes
+
+
+
Change encoding function signature to prevent+misuse
+
Change contrib/tsearch2 to avoid unsafe use of+INTERNAL function results
+
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.
+
+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.
+
+
Ensure operations done during backend shutdown are counted by+statistics collector
+ This is expected to resolve reports of
pg_autovacuum+ not vacuuming the system catalogs often enough — it was not being
+ told about catalog deletions caused by temporary table removal during
+ backend exit.
+
+
Additional buffer overrun checks in plpgsql+(Neil)
+
Fix pg_dump to dump trigger names containing %+correctly (Neil)
+
Fix contrib/pgcrypto for newer OpenSSL builds+(Marko Kreen)
+
Still more 64-bit fixes for+contrib/intagg
+
Prevent incorrect optimization of functions returning+RECORD
+
Prevent to_char(interval) from dumping core for+month-related formats
+
Prevent crash on COALESCE(NULL,NULL)+
Fix array_map to call PL functions correctly+
Fix permission checking in ALTER DATABASE RENAME+
Fix ALTER LANGUAGE RENAME+
Make RemoveFromWaitQueue clean up after itself+This fixes a lock management error that would only be visible if a transaction
+was kicked out of a wait for a lock (typically by query cancel) and then the
+holder of the lock released it within a very narrow window.
+
+
Fix problem with untyped parameter appearing in+INSERT ... SELECT
+
Fix CLUSTER failure after+ALTER TABLE SET WITHOUT OIDS
+
+
+
+
Release 7.3.10
+
+
+
Release date
+ 2005-05-05
+
+
+ This release contains a variety of fixes from 7.3.9, including several
+ security-related issues.
+
+
+
+
Migration to version 7.3.10
+
+ 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 may 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[3] = 'internal'::regtype
+WHERE pronamespace = 11 AND pronargs = 5
+ AND proargtypes[2] = '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, 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
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+
+ Next connect to template0 and 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';
+
+
+
+
+
+
Changes
+
+
+
Change encoding function signature to prevent+misuse
+
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.
+
+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.
+
+
Additional buffer overrun checks in plpgsql+(Neil)
+
Fix pg_dump to dump trigger names containing %+correctly (Neil)
+
Prevent to_char(interval) from dumping core for+month-related formats
+
Fix contrib/pgcrypto for newer OpenSSL builds+(Marko Kreen)
+
Still more 64-bit fixes for+contrib/intagg
+
Prevent incorrect optimization of functions returning+RECORD
+
+
+
+
+
Release 7.3.9
projects / postgresql.git / commitdiff