| 14
|
|
|
Matthias Klose |
9.3.2-1ubuntu2 |
10 years ago
|
 |
|
| 13
|
|
|
Matthias Klose |
9.3.2-1ubuntu1 |
10 years ago
|
|
|
| 12
|
|
[ 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 |
9.3.2-1 |
10 years ago
|
|
|
| 11
|
|
|
Martin Pitt |
9.3.1-1 |
10 years ago
|
|
|
| 10
|
|
|
Christoph Berg |
9.3.0-2 |
10 years ago
|
|
|
| 9
|
|
|
Christoph Berg |
9.3.0-1 |
10 years ago
|
|
|
| 8
|
|
|
Martin Pitt |
9.3~rc1-2 |
10 years ago
|
|
|
| 7
|
|
|
Martin Pitt |
9.3~rc1-1 |
10 years ago
|
|
|
| 6
|
|
|
Martin Pitt |
9.3~beta2-2 |
10 years ago
|
|
|
| 5
|
|
|
Martin Pitt |
9.3~beta2-1 |
10 years ago
|
|
|
| 4
|
|
|
Christoph Berg |
9.3~beta1-3 |
11 years ago
|
|
|
| 3
|
|
|
Christoph Berg |
9.3~beta1-2 |
11 years ago
|
|
|
| 2
|
|
|
Martin Pitt |
9.3~beta1-1 |
11 years ago
|
|
|
| 1
|
|
|
Martin Pitt |
upstream-9.3~beta1 |
11 years ago
|
|
|
collapse all