-
postgresql-9.3 (9.3.24-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream release (LP: #1786938)
- Fix failure to reset libpq's state fully between connection attempts
.
An unprivileged user of dblink or postgres_fdw could bypass the checks
intended to prevent use of server-side credentials, such as a ~/.pgpass
file owned by the operating-system user running the server. Servers
allowing peer authentication on local connections are particularly
vulnerable. Other attacks such as SQL injection into a postgres_fdw
session are also possible. Attacking postgres_fdw in this way requires
the ability to create a foreign server object with selected connection
parameters, but any user with access to dblink could exploit the
problem. In general, an attacker with the ability to select the
connection parameters for a libpq-using application could cause
mischief, though other plausible attack scenarios are harder to think
of. Our thanks to Andrew Krasichkov for reporting this issue.
(CVE-2018-10915)
- d/libecpg-dev.install: Add new pgtypes header.
- d/libpgtypes3.symbols: Add new pgtypes symbol.
- Details about these and other changes can be found at
https://www.postgresql.org/docs/9.3/static/release-9-3-24.html
-- Christian Ehrhardt <email address hidden> Tue, 14 Aug 2018 14:49:12 +0200
-
postgresql-9.3 (9.3.23-0ubuntu0.14.04) trusty; urgency=medium
* New upstream release (LP: #1769888)
- A dump/restore is not required for those running 9.3.X.
However, if the function marking mistakes mentioned in the first
changelog entry affect you, you will want to take steps to
correct your database catalogs.
- Details about changes can be found at
https://www.postgresql.org/docs/9.3/static/release-9-3-23.html
-- Christian Ehrhardt <email address hidden> Tue, 08 May 2018 15:17:51 +0200
-
postgresql-9.3 (9.3.22-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream release (LP: #1752271)
If you run an installation in which not all users are mutually
trusting, or if you maintain an application or extension that is
intended for use in arbitrary situations, it is strongly recommended
that you read the documentation changes described in the first changelog
entry below, and take suitable steps to ensure that your installation or
code is secure.
Also, the changes described in the second changelog entry below may
cause functions used in index expressions or materialized views to fail
during auto-analyze, or when reloading from a dump. After upgrading,
monitor the server logs for such problems, and fix affected functions.
- Document how to configure installations and applications to guard
against search-path-dependent trojan-horse attacks from other users
Using a search_path setting that includes any schemas writable by a
hostile user enables that user to capture control of queries and then
run arbitrary SQL code with the permissions of the attacked user. While
it is possible to write queries that are proof against such hijacking,
it is notationally tedious, and it's very easy to overlook holes.
Therefore, we now recommend configurations in which no untrusted schemas
appear in one's search path.
(CVE-2018-1058)
- Avoid use of insecure search_path settings in pg_dump and other client
programs
pg_dump, pg_upgrade, vacuumdb and other PostgreSQL-provided applications
were themselves vulnerable to the type of hijacking described in the
previous changelog entry; since these applications are commonly run by
superusers, they present particularly attractive targets. To make them
secure whether or not the installation as a whole has been secured,
modify them to include only the pg_catalog schema in their search_path
settings. Autovacuum worker processes now do the same, as well.
In cases where user-provided functions are indirectly executed by these
programs -- for example, user-provided functions in index expressions --
the tighter search_path may result in errors, which will need to be
corrected by adjusting those user-provided functions to not assume
anything about what search path they are invoked under. That has always
been good practice, but now it will be necessary for correct behavior.
(CVE-2018-1058)
- Details about other changes can be found at
https://www.postgresql.org/docs/9.3/static/release-9-3-22.html
-- Christian Ehrhardt <email address hidden> Wed, 28 Feb 2018 09:59:05 +0100
-
postgresql-9.3 (9.3.21-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream release (LP: #1747676)
- Ensure that all temporary files made by pg_upgrade are non-world-readable
(CVE-2018-1053)
- Details about other changes at full changelog:
https://www.postgresql.org/docs/9.3/static/release-9-3-21.html
-- Christian Ehrhardt <email address hidden> Tue, 06 Feb 2018 15:19:51 +0100
-
postgresql-9.3 (9.3.20-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream release (LP: #1730661)
- Details about other changes at full changelog:
https://www.postgresql.org/docs/9.3/static/release-9-3-20.html
-- Christian Ehrhardt <email address hidden> Tue, 07 Nov 2017 14:33:47 +0100
-
postgresql-9.3 (9.3.19-0ubuntu0.14.04) trusty; urgency=medium
* New upstream release (LP: #1713979)
- fix upgrade regressions of the former security release
- Details about other changes at full changelog:
https://www.postgresql.org/docs/9.3/static/release-9-3-19.html
-- Christian Ehrhardt <email address hidden> Wed, 30 Aug 2017 13:00:40 +0200
-
postgresql-9.3 (9.3.18-0ubuntu0.14.04.1) trusty-security; urgency=medium
* SECURITY UPDATE: Update to 9.3.18 to fix security issues
- Further restrict visibility of pg_user_mappings.umoptions, to protect
passwords stored as user mapping options (CVE-2017-7547)
- Disallow empty passwords in all password-based authentication methods
(CVE-2017-7546)
- Make lo_put() check for UPDATE privilege on the target large object
(CVE-2017-7548)
-- Marc Deslauriers <email address hidden> Mon, 14 Aug 2017 10:28:33 -0400
-
postgresql-9.3 (9.3.17-0ubuntu0.14.04) trusty; urgency=medium
* New upstream release (LP: #1690730)
- Restrict visibility of pg_user_mappings.umoptions, to protect passwords
stored as user mapping options (CVE-2017-7486)
- Prevent exposure of statistical information via leaky operators
(CVE-2017-7484)
- Restore libpq's recognition of the PGREQUIRESSL environment variable
(CVE-2017-7485)
- A dump/restore is not required for those running 9.3.X.
- However, if you use foreign data servers that make use of user passwords
for authentication, see the first changelog entry.
- Details about other changes at full changelog:
https://www.postgresql.org/docs/9.3/static/release-9-3-17.html
-- Christian Ehrhardt <email address hidden> Mon, 15 May 2017 08:45:01 +0200
-
postgresql-9.3 (9.3.16-0ubuntu0.14.04) trusty; urgency=medium
* New upstream release (LP: #1664478)
- Fix a race condition that could cause indexes built with CREATE INDEX
CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane).
If CREATE INDEX CONCURRENTLY was used to build an index that depends on
a column not previously indexed, then rows inserted or updated by
transactions that ran concurrently with the CREATE INDEX command could
have received incorrect index entries. If you suspect this may have
happened, the most reliable solution is to rebuild affected indexes
after installing this update
- Details about other changes:
https://www.postgresql.org/docs/9.3/static/release-9-3-16.html
-- Christian Ehrhardt <email address hidden> Tue, 14 Feb 2017 09:29:18 +0100
-
postgresql-9.3 (9.3.15-0ubuntu0.14.04) trusty-proposed; urgency=medium
* New upstream bug fix release (LP: #1637236)
- Fix WAL-logging of truncation of relation free space maps and visibility
maps.
It was possible for these files to not be correctly restored during
crash recovery, or to be written incorrectly on a standby server. Bogus
entries in a free space map could lead to attempts to access pages that
have been truncated away from the relation itself, typically producing
errors like "could not read block XXX: read only 0 of 8192 bytes".
Checksum failures in the visibility map are also possible, if
checksumming is enabled.
Procedures for determining whether there is a problem and repairing it
if so are discussed at
https://wiki.postgresql.org/wiki/Free_Space_Map_Problems
- Details about other changes:
http://www.postgresql.org/docs/9.3/static/release-9-3-15.html
-- Martin Pitt <email address hidden> Thu, 27 Oct 2016 21:20:52 +0200
-
postgresql-9.3 (9.3.14-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream security/bug fix release (LP: #1614113):
- Fix possible mis-evaluation of nested CASE-WHEN expressions
A CASE expression appearing within the test value subexpression of
another CASE could become confused about whether its own test value was
null or not. Also, inlining of a SQL function implementing the equality
operator used by a CASE expression could result in passing the wrong
test value to functions called within a CASE expression in the SQL
function's body. If the test values were of different data types, a
crash might result; moreover such situations could be abused to allow
disclosure of portions of server memory. (CVE-2016-5423)
- Fix client programs' handling of special characters in database and role
names
Numerous places in vacuumdb and other client programs could become
confused by database and role names containing double quotes or
backslashes. Tighten up quoting rules to make that safe. Also, ensure
that when a conninfo string is used as a database name parameter to
these programs, it is correctly treated as such throughout.
Fix handling of paired double quotes in psql's \connect and \password
commands to match the documentation.
Introduce a new -reuse-previous option in psql's \connect command to
allow explicit control of whether to re-use connection parameters from a
previous connection. (Without this, the choice is based on whether the
database name looks like a conninfo string, as before.) This allows
secure handling of database names containing special characters in
pg_dumpall scripts.
pg_dumpall now refuses to deal with database and role names containing
carriage returns or newlines, as it seems impractical to quote those
characters safely on Windows. In future we may reject such names on the
server side, but that step has not been taken yet.
These are considered security fixes because crafted object names
containing special characters could have been used to execute commands
with superuser privileges the next time a superuser executes pg_dumpall
or other routine maintenance operations. (CVE-2016-5424)
- Details: http://www.postgresql.org/docs/9.3/static/release-9-3-14.html
-- Martin Pitt <email address hidden> Wed, 17 Aug 2016 16:37:41 +0200
-
postgresql-9.3 (9.3.13-0ubuntu0.14.04) trusty-proposed; urgency=medium
* New upstream bug fix release. (LP: #1581016)
- See http://www.postgresql.org/docs/9.3/static/release-9-3-13.html for
details.
-- Martin Pitt <email address hidden> Thu, 12 May 2016 16:06:03 +0200
-
postgresql-9.3 (9.3.12-0ubuntu0.14.04) trusty-proposed; urgency=medium
* New upstream bug fix release. (LP: #1564268)
- See http://www.postgresql.org/about/news/1656/ for details.
-- Martin Pitt <email address hidden> Thu, 31 Mar 2016 11:04:53 +0200
-
postgresql-9.3 (9.3.11-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream security/bug fix release: (LP: #1544576)
- Fix infinite loops and buffer-overrun problems in regular expressions.
Very large character ranges in bracket expressions could cause infinite
loops in some cases, and memory overwrites in other cases.
(CVE-2016-0773)
- Prevent certain PL/Java parameters from being set by non-superusers.
This change mitigates a PL/Java security bug (CVE-2016-0766), which was
fixed in PL/Java by marking these parameters as superuser-only. To fix
the security hazard for sites that update PostgreSQL more frequently
than PL/Java, make the core code aware of them also.
- See release notes for details about other fixes.
-- Martin Pitt <email address hidden> Thu, 11 Feb 2016 15:44:43 +0100
-
postgresql-9.3 (9.3.10-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream security/bug fix release: (LP: #1504132)
- Guard against stack overflows in json parsing.
If an application constructs PostgreSQL json or jsonb values from
arbitrary user input, the application's users can reliably crash the
PostgreSQL server, causing momentary denial of service. (CVE-2015-5289)
- Fix contrib/pgcrypto to detect and report too-short crypt() salts
Certain invalid salt arguments crashed the server or disclosed a few
bytes of server memory. We have not ruled out the viability of attacks
that arrange for presence of confidential information in the disclosed
bytes, but they seem unlikely. (CVE-2015-5288)
- See release notes for details about other fixes.
-- Martin Pitt <email address hidden> Thu, 08 Oct 2015 15:42:16 +0200
-
postgresql-9.3 (9.3.9-0ubuntu0.14.04) trusty-proposed; urgency=medium
* New upstream bug fix release (LP: #1464669)
- Fix possible failure to recover from an inconsistent database state
- Fix rare failure to invalidate relation cache init file
- See http://www.postgresql.org/about/news/1592/ for details.
-- Martin Pitt <email address hidden> Fri, 12 Jun 2015 15:59:10 +0200
-
postgresql-9.3 (9.3.8-0ubuntu0.4.04) trusty-proposed; urgency=medium
* New upstream bug fix release (LP: #1461425)
- Avoid failures while fsync'ing data directory during crash restart.
In the previous minor releases we added a patch to fsync everything in
the data directory after a crash. Unfortunately its response to any
error condition was to fail, thereby preventing the server from starting
up, even when the problem was quite harmless. An example is that an
unwritable file in the data directory would prevent restart on some
platforms; but it is common to make SSL certificate files unwritable by
the server. Revise this behavior so that permissions failures are
ignored altogether, and other types of failures are logged but do not
prevent continuing.
- See release notes for details about other fixes.
-- Martin Pitt <email address hidden> Wed, 03 Jun 2015 09:54:24 +0200
-
postgresql-9.3 (9.3.7-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream security/bug fix release (LP: #1457093)
- Avoid possible crash when client disconnects just before the
authentication timeout expires.
If the timeout interrupt fired partway through the session shutdown
sequence, SSL-related state would be freed twice, typically causing a
crash and hence denial of service to other sessions. Experimentation
shows that an unauthenticated remote attacker could trigger the bug
somewhat consistently, hence treat as security issue. (CVE-2015-3165)
- Improve detection of system-call failures
Our replacement implementation of snprintf() failed to check for errors
reported by the underlying system library calls; the main case that
might be missed is out-of-memory situations. In the worst case this
might lead to information exposure, due to our code assuming that a
buffer had been overwritten when it hadn't been. Also, there were a few
places in which security-relevant calls of other system library
functions did not check for failure.
It remains possible that some calls of the *printf() family of functions
are vulnerable to information disclosure if an out-of-memory error
occurs at just the wrong time. We judge the risk to not be large, but
will continue analysis in this area. (CVE-2015-3166)
- In contrib/pgcrypto, uniformly report decryption failures as Wrong key
or corrupt data
Previously, some cases of decryption with an incorrect key could report
other error message texts. It has been shown that such variance in
error reports can aid attackers in recovering keys from other systems.
While it's unknown whether pgcrypto's specific behaviors are likewise
exploitable, it seems better to avoid the risk by using a
one-size-fits-all message. (CVE-2015-3167)
- Protect against wraparound of multixact member IDs
Under certain usage patterns, the existing defenses against this might
be insufficient, allowing pg_multixact/members files to be removed too
early, resulting in data loss.
The fix for this includes modifying the server to fail transactions that
would result in overwriting old multixact member ID data, and improving
autovacuum to ensure it will act proactively to prevent multixact member
ID wraparound, as it does for transaction ID wraparound.
- See release notes for details about other fixes.
-- Martin Pitt <email address hidden> Wed, 20 May 2015 23:08:58 +0200
-
postgresql-9.3 (9.3.6-0ubuntu0.14.04) trusty-security; urgency=medium
* New upstream security/bug fix release (LP: #1418928)
- Fix buffer overruns in to_char() [CVE-2015-0241]
- Fix buffer overruns in contrib/pgcrypto [CVE-2015-0243]
- Fix possible loss of frontend/backend protocol synchronization after an
error [CVE-2015-0244]
- Fix information leak via constraint-violation error messages
[CVE-2014-8161]
- See release notes for details about other fixes:
http://www.postgresql.org/about/news/1569/
-- Martin Pitt <email address hidden> Fri, 06 Feb 2015 12:47:00 +0100
-
postgresql-9.3 (9.3.5-0ubuntu0.14.04.1) trusty-proposed; urgency=medium
* New upstream bug fix release: (LP: #1348176)
- pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
an issue with transaction information which causes VACUUM to eventually
fail. These users should run the script provided in the release notes to
determine if their installation is affected, and then take the remedy
steps outlined there.
- Various data integrity and other bug fixes.
- Secure Unix-domain sockets of temporary postmasters started during make
check.
Any local user able to access the socket file could connect as the
server's bootstrap superuser, then proceed to execute arbitrary code as
the operating-system user running the test, as we previously noted in
CVE-2014-0067. This change defends against that risk by placing the
server's socket in a temporary, mode 0700 subdirectory of /tmp.
- See release notes for details:
http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.
-- Martin Pitt <email address hidden> Thu, 24 Jul 2014 16:13:59 +0200
-
postgresql-9.3 (9.3.4-1) unstable; urgency=medium
* New upstream bugfix release. Most notable change:
Fix WAL replay of locking an already-updated tuple (Andres Freund,
Álvaro Herrera)
This error caused updated rows to not be found by index scans, resulting
in inconsistent query results depending on whether an index scan was used.
Subsequent processing could result in constraint violations, since the
previously updated row would not be found by later index searches, thus
possibly allowing conflicting rows to be inserted. Since this error is in
WAL replay, it would only manifest during crash recovery or on standby
servers. The improperly-replayed case most commonly arises when a table
row that is referenced by a foreign-key constraint is updated concurrently
with creation of a referencing row.
* Compile with -fno-omit-frame-pointer on amd64 to facilitate hierarchical
profile generation. (Closes: #730134)
* Remove obsolete configure option --with-tkconfig.
-- Christoph Berg <email address hidden> Tue, 18 Mar 2014 07:19:37 +0100
-
postgresql-9.3 (9.3.3-1bzr2) trusty; urgency=medium
Upload current Debian packaging bzr to fix autopkgtest in LXC.
* Add missing build-essential test depends, for 180_ecpg.t.
-- Martin Pitt <email address hidden> Fri, 21 Feb 2014 16:14:59 -0800
-
postgresql-9.3 (9.3.3-1bzr1) trusty; urgency=medium
* Add missing gcc test depends, for 180_ecpg.t.
-- Martin Pitt <email address hidden> Thu, 20 Feb 2014 22:26:18 -0800
-
postgresql-9.3 (9.3.3-1) unstable; urgency=medium
[ Christoph Berg ]
* New upstream security/bugfix release.
+ Shore up GRANT ... WITH ADMIN OPTION restrictions (Noah Misch)
Granting a role without ADMIN OPTION is supposed to prevent the grantee
from adding or removing members from the granted role, but this
restriction was easily bypassed by doing SET ROLE first. The security
impact is mostly that a role member can revoke the access of others,
contrary to the wishes of his grantor. Unapproved role member additions
are a lesser concern, since an uncooperative role member could provide
most of his rights to others anyway by creating views or SECURITY
DEFINER functions. (CVE-2014-0060)
+ Prevent privilege escalation via manual calls to PL validator functions
(Andres Freund)
The primary role of PL validator functions is to be called implicitly
during CREATE FUNCTION, but they are also normal SQL functions that a
user can call explicitly. Calling a validator on a function actually
written in some other language was not checked for and could be
exploited for privilege-escalation purposes. The fix involves adding a
call to a privilege-checking function in each validator function.
Non-core procedural languages will also need to make this change to
their own validator functions, if any. (CVE-2014-0061)
+ Avoid multiple name lookups during table and index DDL (Robert Haas,
Andres Freund)
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be used
to cause the permissions checks to be performed against a different
table than the index creation, allowing for a privilege escalation
attack. (CVE-2014-0062)
+ Prevent buffer overrun with long datetime strings (Noah Misch)
The MAXDATELEN constant was too small for the longest possible value of
type interval, allowing a buffer overrun in interval_out(). Although the
datetime input functions were more careful about avoiding buffer
overrun, the limit was short enough to cause them to reject some valid
inputs, such as input containing a very long timezone name. The ecpg
library contained these vulnerabilities along with some of its own.
(CVE-2014-0063)
+ Prevent buffer overrun due to integer overflow in size calculations
(Noah Misch, Heikki Linnakangas)
Several functions, mostly type input functions, calculated an allocation
size without checking for overflow. If overflow did occur, a too-small
buffer would be allocated and then written past. (CVE-2014-0064)
+ Prevent overruns of fixed-size buffers (Peter Eisentraut, Jozef Mlich)
Use strlcpy() and related functions to provide a clear guarantee that
fixed-size buffers are not overrun. Unlike the preceding items, it is
unclear whether these cases really represent live issues, since in most
cases there appear to be previous constraints on the size of the input
string. Nonetheless it seems prudent to silence all Coverity warnings of
this type. (CVE-2014-0065)
+ Avoid crashing if crypt() returns NULL (Honza Horak, Bruce Momjian)
There are relatively few scenarios in which crypt() could return NULL,
but contrib/chkpass would crash if it did. One practical case in which
this could be an issue is if libc is configured to refuse to execute
unapproved hashing algorithms (e.g., "FIPS mode"). (CVE-2014-0066)
+ Document risks of make check in the regression testing instructions
(Noah Misch, Tom Lane)
Since the temporary server started by make check uses "trust"
authentication, another user on the same machine could connect to it as
database superuser, and then potentially exploit the privileges of the
operating-system user who started the tests. A future release will
probably incorporate changes in the testing procedure to prevent this
risk, but some public discussion is needed first. So for the moment,
just warn people against using make check when there are untrusted users
on the same machine. (CVE-2014-0067)
+ Rework tuple freezing protocol (Álvaro Herrera, Andres Freund)
The logic for tuple freezing was unable to handle some cases involving
freezing of multixact IDs, with the practical effect that shared
row-level locks might be forgotten once old enough.
Fixing this required changing the WAL record format for tuple freezing.
While this is no issue for standalone servers, when using replication it
means that standby servers must be upgraded to 9.3.3 or later before
their masters are. An older standby will be unable to interpret freeze
records generated by a newer master, and will fail with a PANIC message.
(In such a case, upgrading the standby should be sufficient to let it
resume execution.)
* The upstream tarballs no longer contain a plain HISTORY file, but point to
the html documentation. Note the location of these files in our
changelog.gz file.
* Teach configure to find tclsh8.6 where tclsh is not available.
[ Martin Pitt ]
* Build with LINUX_OOM_SCORE_ADJ=0 instead of the older LINUX_OOM_ADJ=0. All
relevant distro releases (>= squeeze/lucid) use kernels which support
/proc/pid/oom_score_adj, so avoid the dmesg warnings. (Closes: #646245,
LP: #991725)
* Bump Standards-Version to 3.9.5 (no changes necessary).
* Build with tcl8.6 where available (>= Jessie, >= trusty).
-- Christoph Berg <email address hidden> Wed, 19 Feb 2014 10:15:39 +0100
-
postgresql-9.3 (9.3.2-1ubuntu2) trusty; urgency=medium
* No-change rebuild for Python 3.4.
-- Matthias Klose <email address hidden> Wed, 19 Feb 2014 12:03:01 +0100
-
postgresql-9.3 (9.3.2-1ubuntu1) trusty; urgency=medium
* Build for Tcl 8.6.
-- Matthias Klose <email address hidden> Thu, 02 Jan 2014 18:11:45 +0100
-
postgresql-9.3 (9.3.2-1) unstable; urgency=low
[ Martin Pitt ]
* Add 03-config-update.patch: Refresh config.{guess,sub} to latest version
for enabling ports, in particular the upcoming ppc64el.
[ Christoph Berg ]
* New upstream bugfix release.
+ Fix "VACUUM"'s tests to see whether it can update relfrozenxid
(Andres Freund)
In some cases "VACUUM" (either manual or autovacuum) could
incorrectly advance a table's relfrozenxid value, allowing tuples
to escape freezing, causing those rows to become invisible once
2^31 transactions have elapsed. The probability of data loss is
fairly low since multiple incorrect advancements would need to
happen before actual loss occurs, but it's not zero. In 9.2.0 and
later, the probability of loss is higher, and it's also possible to
get "could not access status of transaction" errors as a
consequence of this bug. Users upgrading from releases 9.0.4 or
8.4.8 or earlier are not affected, but all later versions contain
the bug.
The issue can be ameliorated by, after upgrading, vacuuming all
tables in all databases while having vacuum_freeze_table_age set to
zero. This will fix any latent corruption but will not be able to
fix all pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has executed
fewer than 2^31 update transactions in its lifetime (check this
with SELECT txid_current() < 2^31).
+ Fix multiple bugs in MultiXactId freezing (Andres Freund, Alvaro
Herrera)
These bugs could lead to "could not access status of transaction"
errors, or to duplicate or vanishing rows. Users upgrading from
releases prior to 9.3.0 are not affected.
The issue can be ameliorated by, after upgrading, vacuuming all
tables in all databases while having vacuum_freeze_table_age set to
zero. This will fix latent corruption but will not be able to fix
all pre-existing data errors.
As a separate issue, these bugs can also cause standby servers to
get out of sync with the primary, thus exhibiting data errors that
are not in the primary. Therefore, it's recommended that 9.3.0 and
9.3.1 standby servers be re-cloned from the primary (e.g., with a
new base backup) after upgrading.
+ Fix initialization of "pg_clog" and "pg_subtrans" during hot
standby startup (Andres Freund, Heikki Linnakangas)
This bug can cause data loss on standby servers at the moment they
start to accept hot-standby queries, by marking committed
transactions as uncommitted. The likelihood of such corruption is
small unless, at the time of standby startup, the primary server
has executed many updating transactions since its last checkpoint.
Symptoms include missing rows, rows that should have been deleted
being still visible, and obsolete versions of updated rows being
still visible alongside their newer versions.
This bug was introduced in versions 9.3.0, 9.2.5, 9.1.10, and
9.0.14. Standby servers that have only been running earlier
releases are not at risk. It's recommended that standby servers
that have ever run any of the buggy releases be re-cloned from the
primary (e.g., with a new base backup) after upgrading.
* Refresh debian/patches/62-pg_upgrade-test-in-tmp.
-- Christoph Berg <email address hidden> Tue, 03 Dec 2013 09:18:41 +0100
-
postgresql-9.3 (9.3.1-1) unstable; urgency=low
* New upstream release.
- Update hstore extension with JSON functionality
Users who installed hstore prior to 9.3.1 must execute:
ALTER EXTENSION hstore UPDATE;
to add two new JSON functions and a cast.
- Some bug fixes, see HISTORY for details.
-- Martin Pitt <email address hidden> Tue, 08 Oct 2013 10:54:46 +0200
