However, a longstanding error was discovered in the definition
of the information_schema.referential_constraints view. If
you rely on correct results from that view, you should replace its
definition as explained in the first changelog item below.

Also, if you use the citext data type, and
you upgraded from a previous major release by running pg_upgrade, you should run CREATE EXTENSION citext FROM unpackaged to avoid
collation-related failures in citext
operations. The same is necessary if you restore a dump from a
pre-9.1 database that contains an instance of the citext data type. If you've already run the CREATE EXTENSION command before upgrading to 9.1.2,
you will instead need to do manual catalog updates as explained in
the second changelog item.

This view was being insufficiently careful about matching the
foreign-key constraint to the depended-on primary or unique key
constraint. That could result in failure to show a foreign key
constraint at all, or showing it multiple times, or claiming that
it depends on a different constraint than the one it really
does.

Since the view definition is installed by initdb, merely upgrading will not fix the
problem. If you need to fix this in an existing installation, you
can (as a superuser) drop the information_schema schema then re-create it by
sourcing SHAREDIR/information_schema.sql. (Run
pg_config --sharedir if you're uncertain
where SHAREDIR is.) This must be
repeated in each database to be fixed.

Existing citext columns and indexes aren't
correctly marked as being of a collatable data type during
pg_upgrade from a pre-9.1 server,
or when a pre-9.1 dump containing the citext
type is loaded into a 9.1 server. That leads to operations on these
columns failing with errors such as "could not
determine which collation to use for string comparison".
This change allows them to be fixed by the same script that
upgrades the citext module into a proper 9.1
extension during CREATE EXTENSION citext FROM
unpackaged.

If you have a previously-upgraded database that is suffering
from this problem, and you already ran the CREATE EXTENSION command, you can manually run (as
superuser) the UPDATE commands found at
the end of SHAREDIR/extension/citext--unpackaged--1.0.sql.
(Run pg_config --sharedir if you're
uncertain where SHAREDIR is.) There
is no harm in doing this again if unsure.

Fix possible crash during UPDATE or
DELETE that joins to the output of a
scalar-returning function (Tom Lane)

A crash could only occur if the target row had been concurrently
updated, so this problem surfaced only intermittently.

Fix incorrect replay of WAL records for GIN index updates (Tom
Lane)

This could result in transiently failing to find index entries
after a crash, or on a hot-standby server. The problem would be
repaired by the next VACUUM of the index,
however.

If a table has been modified by ALTER TABLE
ADD COLUMN, attempts to copy its data verbatim to another
table could produce corrupt results in certain corner cases. The
problem can only manifest in this precise form in 8.4 and later,
but we patched earlier versions as well in case there are other
code paths that could trigger the same bug.

The typical symptom was transient errors like "missing chunk number 0 for toast value NNNNN in
pg_toast_2619", where the cited toast table would always
belong to a system catalog.

Track dependencies of functions on items used in parameter
default expressions (Tom Lane)

Previously, a referenced object could be dropped without having
dropped or modified the function, leading to misbehavior when the
function was used. Note that merely installing this update will not
fix the missing dependency entries; to do that, you'd need to
CREATE OR REPLACE each such function
afterwards. If you have functions whose defaults depend on
non-built-in objects, doing so is recommended.

Fix index matching for operators with both collatable and
noncollatable inputs (Tom Lane)

In 9.1.0, an indexable operator that has a non-collatable
left-hand input type and a collatable right-hand input type would
not be recognized as matching the left-hand column's index. An
example is the hstore?text operator.

For a cascading foreign key that references its own table, a row
update will fire both the ON UPDATE
trigger and the CHECK trigger as one
event. The ON UPDATE trigger must execute
first, else the CHECK will check a
non-final state of the row and possibly throw an inappropriate
error. However, the firing order of these triggers is determined by
their names, which generally sort in creation order since the
triggers have auto-generated names following the convention
"RI_ConstraintTrigger_NNNN". A proper
fix would require modifying that convention, which we will do in
9.2, but it seems risky to change it in existing releases. So this
patch just changes the creation order of the triggers. Users
encountering this type of error should drop and re-create the
foreign key constraint to get its triggers into the right
order.

Fix IF EXISTS to work correctly in
DROP OPERATOR FAMILY (Robert Haas)

Disallow dropping of an extension from within its own script
(Tom Lane)

This prevents odd behavior in case of incorrect management of
extension dependencies.

Don't mark auto-generated types as extension members (Robert
Haas)

Relation rowtypes and automatically-generated array types do not
need to have their own extension membership entries in pg_depend, and creating such entries complicates
matters for extension upgrades.

Autovacuum formerly used the cluster-wide default transaction
isolation level, but there is no need for it to use anything higher
than READ COMMITTED, and using SERIALIZABLE could result in
unnecessary delays for other processes.

Restore the pre-9.1 behavior that PL/Perl functions returning
void ignore the result value of their last
Perl statement; 9.1.0 would throw an error if that statement
returned a reference. Also, make sure it works to return a string
value for a composite type, so long as the string meets the type's
input format. In addition, throw errors for attempts to return Perl
arrays or hashes when the function's declared result type is not an
array or composite type, respectively. (Pre-9.1 versions rather
uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90) in such cases.)