Just thought I'll share a “fun" story. Friend reported weird bug – OmniPITR reported that xlogs are sent to archive, but they actually weren't.
After some checking we found out that he was giving custom rsync-path (–rsync-path – path to rsync program) – and the path was broken.
In this case – OmniPITR was not reporting error, and quite happily was working under assumption that it works OK.
Continue reading Fixed a bug in OmniPITR
Otto Bretz reported bug in OmniPITR.
The bug was that when using -dr (remote destinations for backups) – you couldn't use –skip-xlogs. Obvious overlook on my side.
Fix was trivial, and so 1.3.2 version was born.
In release notes to latest release you can find:
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).
What does it really mean?
Continue reading What does “Fix VACUUM's tests to see whether it can update relfrozenxid" really mean?