|
|
|
@ -1,6 +1,318 @@ |
|
|
|
<!-- doc/src/sgml/release-8.4.sgml --> |
|
|
|
<!-- doc/src/sgml/release-8.4.sgml --> |
|
|
|
<!-- See header comment in release.sgml about typical markup --> |
|
|
|
<!-- See header comment in release.sgml about typical markup --> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1 id="release-8-4-11"> |
|
|
|
|
|
|
|
<title>Release 8.4.11</title> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<note> |
|
|
|
|
|
|
|
<title>Release Date</title> |
|
|
|
|
|
|
|
<simpara>2012-02-27</simpara> |
|
|
|
|
|
|
|
</note> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
This release contains a variety of fixes from 8.4.10. |
|
|
|
|
|
|
|
For information about new features in the 8.4 major release, see |
|
|
|
|
|
|
|
<xref linkend="release-8-4">. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect2> |
|
|
|
|
|
|
|
<title>Migration to Version 8.4.11</title> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
A dump/restore is not required for those running 8.4.X. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
However, if you are upgrading from a version earlier than 8.4.10, |
|
|
|
|
|
|
|
see the release notes for 8.4.10. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</sect2> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect2> |
|
|
|
|
|
|
|
<title>Changes</title> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<itemizedlist> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix btree index corruption from insertions concurrent with vacuuming |
|
|
|
|
|
|
|
(Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
An index page split caused by an insertion could sometimes cause a |
|
|
|
|
|
|
|
concurrently-running <command>VACUUM</> to miss removing index entries |
|
|
|
|
|
|
|
that it should remove. After the corresponding table rows are removed, |
|
|
|
|
|
|
|
the dangling index entries would cause errors (such as <quote>could not |
|
|
|
|
|
|
|
read block N in file ...</>) or worse, silently wrong query results |
|
|
|
|
|
|
|
after unrelated rows are re-inserted at the now-free table locations. |
|
|
|
|
|
|
|
This bug has been present since release 8.2, but occurs so infrequently |
|
|
|
|
|
|
|
that it was not diagnosed until now. If you have reason to suspect |
|
|
|
|
|
|
|
that it has happened in your database, reindexing the affected index |
|
|
|
|
|
|
|
will fix things. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Update per-column permissions, not only per-table permissions, when |
|
|
|
|
|
|
|
changing table owner (Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Failure to do this meant that any previously granted column permissions |
|
|
|
|
|
|
|
were still shown as having been granted by the old owner. This meant |
|
|
|
|
|
|
|
that neither the new owner nor a superuser could revoke the |
|
|
|
|
|
|
|
now-untraceable-to-table-owner permissions. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Allow non-existent values for some settings in <command>ALTER |
|
|
|
|
|
|
|
USER/DATABASE SET</> (Heikki Linnakangas) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Allow <varname>default_text_search_config</>, |
|
|
|
|
|
|
|
<varname>default_tablespace</>, and <varname>temp_tablespaces</> to be |
|
|
|
|
|
|
|
set to names that are not known. This is because they might be known |
|
|
|
|
|
|
|
in another database where the setting is intended to be used, or for the |
|
|
|
|
|
|
|
tablespace cases because the tablespace might not be created yet. The |
|
|
|
|
|
|
|
same issue was previously recognized for <varname>search_path</>, and |
|
|
|
|
|
|
|
these settings now act like that one. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Avoid crashing when we have problems deleting table files post-commit |
|
|
|
|
|
|
|
(Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Dropping a table should lead to deleting the underlying disk files only |
|
|
|
|
|
|
|
after the transaction commits. In event of failure then (for instance, |
|
|
|
|
|
|
|
because of wrong file permissions) the code is supposed to just emit a |
|
|
|
|
|
|
|
warning message and go on, since it's too late to abort the |
|
|
|
|
|
|
|
transaction. This logic got broken as of release 8.4, causing such |
|
|
|
|
|
|
|
situations to result in a PANIC and an unrestartable database. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Track the OID counter correctly during WAL replay, even when it wraps |
|
|
|
|
|
|
|
around (Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Previously the OID counter would remain stuck at a high value until the |
|
|
|
|
|
|
|
system exited replay mode. The practical consequences of that are |
|
|
|
|
|
|
|
usually nil, but there are scenarios wherein a standby server that's |
|
|
|
|
|
|
|
been promoted to master might take a long time to advance the OID |
|
|
|
|
|
|
|
counter to a reasonable value once values are needed. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix regular expression back-references with <literal>*</> attached |
|
|
|
|
|
|
|
(Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Rather than enforcing an exact string match, the code would effectively |
|
|
|
|
|
|
|
accept any string that satisfies the pattern sub-expression referenced |
|
|
|
|
|
|
|
by the back-reference symbol. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
A similar problem still afflicts back-references that are embedded in a |
|
|
|
|
|
|
|
larger quantified expression, rather than being the immediate subject |
|
|
|
|
|
|
|
of the quantifier. This will be addressed in a future |
|
|
|
|
|
|
|
<productname>PostgreSQL</> release. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix recently-introduced memory leak in processing of |
|
|
|
|
|
|
|
<type>inet</>/<type>cidr</> values (Heikki Linnakangas) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
A patch in the December 2011 releases of <productname>PostgreSQL</> |
|
|
|
|
|
|
|
caused memory leakage in these operations, which could be significant |
|
|
|
|
|
|
|
in scenarios such as building a btree index on such a column. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix dangling pointer after <command>CREATE TABLE AS</>/<command>SELECT |
|
|
|
|
|
|
|
INTO</> in a SQL-language function (Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
In most cases this only led to an assertion failure in assert-enabled |
|
|
|
|
|
|
|
builds, but worse consequences seem possible. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Avoid double close of file handle in syslogger on Windows (MauMau) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Ordinarily this error was invisible, but it would cause an exception |
|
|
|
|
|
|
|
when running on a debug version of Windows. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix I/O-conversion-related memory leaks in plpgsql |
|
|
|
|
|
|
|
(Andres Freund, Jan Urbanski, Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Certain operations would leak memory until the end of the current |
|
|
|
|
|
|
|
function. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Improve <application>pg_dump</>'s handling of inherited table columns |
|
|
|
|
|
|
|
(Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
<application>pg_dump</> mishandled situations where a child column has |
|
|
|
|
|
|
|
a different default expression than its parent column. If the default |
|
|
|
|
|
|
|
is textually identical to the parent's default, but not actually the |
|
|
|
|
|
|
|
same (for instance, because of schema search path differences) it would |
|
|
|
|
|
|
|
not be recognized as different, so that after dump and restore the |
|
|
|
|
|
|
|
child would be allowed to inherit the parent's default. Child columns |
|
|
|
|
|
|
|
that are <literal>NOT NULL</> where their parent is not could also be |
|
|
|
|
|
|
|
restored subtly incorrectly. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix <application>pg_restore</>'s direct-to-database mode for |
|
|
|
|
|
|
|
INSERT-style table data (Tom Lane) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Direct-to-database restores from archive files made with |
|
|
|
|
|
|
|
<option>--inserts</> or <option>--column-inserts</> options fail when |
|
|
|
|
|
|
|
using <application>pg_restore</> from a release dated September or |
|
|
|
|
|
|
|
December 2011, as a result of an oversight in a fix for another |
|
|
|
|
|
|
|
problem. The archive file itself is not at fault, and text-mode |
|
|
|
|
|
|
|
output is okay. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Allow <literal>AT</> option in <application>ecpg</> |
|
|
|
|
|
|
|
<literal>DEALLOCATE</> statements (Michael Meskes) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
The infrastructure to support this has been there for awhile, but |
|
|
|
|
|
|
|
through an oversight there was still an error check rejecting the case. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix error in <filename>contrib/intarray</>'s <literal>int[] & |
|
|
|
|
|
|
|
int[]</> operator (Guillaume Lelarge) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
If the smallest integer the two input arrays have in common is 1, |
|
|
|
|
|
|
|
and there are smaller values in either array, then 1 would be |
|
|
|
|
|
|
|
incorrectly omitted from the result. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix error detection in <filename>contrib/pgcrypto</>'s |
|
|
|
|
|
|
|
<function>encrypt_iv()</> and <function>decrypt_iv()</> |
|
|
|
|
|
|
|
(Marko Kreen) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
These functions failed to report certain types of invalid-input errors, |
|
|
|
|
|
|
|
and would instead return random garbage values for incorrect input. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Fix one-byte buffer overrun in <filename>contrib/test_parser</> |
|
|
|
|
|
|
|
(Paul Guyot) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
The code would try to read one more byte than it should, which would |
|
|
|
|
|
|
|
crash in corner cases. |
|
|
|
|
|
|
|
Since <filename>contrib/test_parser</> is only example code, this is |
|
|
|
|
|
|
|
not a security issue in itself, but bad example code is still bad. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Use <function>__sync_lock_test_and_set()</> for spinlocks on ARM, if |
|
|
|
|
|
|
|
available (Martin Pitt) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
This function replaces our previous use of the <literal>SWPB</> |
|
|
|
|
|
|
|
instruction, which is deprecated and not available on ARMv6 and later. |
|
|
|
|
|
|
|
Reports suggest that the old code doesn't fail in an obvious way on |
|
|
|
|
|
|
|
recent ARM boards, but simply doesn't interlock concurrent accesses, |
|
|
|
|
|
|
|
leading to bizarre failures in multiprocess operation. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Use <option>-fexcess-precision=standard</> option when building with |
|
|
|
|
|
|
|
gcc versions that accept it (Andrew Dunstan) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
This prevents assorted scenarios wherein recent versions of gcc will |
|
|
|
|
|
|
|
produce creative results. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Allow use of threaded Python on FreeBSD (Chris Rees) |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
|
|
|
Our configure script previously believed that this combination wouldn't |
|
|
|
|
|
|
|
work; but FreeBSD fixed the problem, so remove that error check. |
|
|
|
|
|
|
|
</para> |
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</itemizedlist> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</sect2> |
|
|
|
|
|
|
|
</sect1> |
|
|
|
|
|
|
|
|
|
|
|
<sect1 id="release-8-4-10"> |
|
|
|
<sect1 id="release-8-4-10"> |
|
|
|
<title>Release 8.4.10</title> |
|
|
|
<title>Release 8.4.10</title> |
|
|
|
|
|
|
|
|
|
|
|
|
Tom Lane
14 years ago