Hello community,
here is the log from the commit of package patchinfo.1452 for
openSUSE:12.3:Update checked in at 2013-03-21 11:16:35
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:12.3:Update/patchinfo.1452 (Old)
and /work/SRC/openSUSE:12.3:Update/.patchinfo.1452.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "patchinfo.1452", Maintainer is ""
Changes:
--------
New Changes file:
NO CHANGES FILE!!!
New:
----
_patchinfo
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ _patchinfo ++++++
<patchinfo>
<packager>AndreasStieger</packager>
<category>recommended</category>
<rating>low</rating>
<summary>xtrabackup: Update to 2.0.5 and fixed path of MySQL 5.5 xtrabackup
binary</summary>
<description>This update fixes the following issues for xtrabackup:
- bnc#809505: fix path of MySQL 5.5 xtrabackup binary
- update to 2.0.5
- new features:
+ New option --defaults-extra-file to read options before the standard
defaults-file, e.g. for separate username/passwords crontab or a script
somewhere in the system.
- bugs fixed:
+ In case of streaming backups, innobackupex would resume the XtraBackup
process and then wait for it to finish before running UNLOCK TABLES. This
caused database to be unnecessarily locked with FLUSH TABLES WITH READ LOCK.
Innobackupex now waits only till log copying is finished to unlock the
databases.
+ innobackupex error messages referencing the data directory have been
extended to show the path of the data directory mentioned in the error message.
+ Partitioned tables were not correctly handled by the --databases,
--include, --tables-file options of innobackupex, and by the --tables and
--tables-file options of XtraBackup.
+ When built-in compression was used, XtraBackup was doing unbuffered
writes to the destination file or stream in very small chunks which in return
caused inefficient I/O.
+ Unnecessary long sleep() in innobackupex lead to FLUSH TABLES WITH READ
LOCK taking too long.
+ If innobackupex would crash it would leave the xtrabackup_suspended file
on the filesystem. This could then cause innobackupex to think XtraBackup has
suspended itself the moment it started, and then when XtraBackup actually does
suspend itself, innobackupex would wait for it to end and wouldn’t re-remove
the suspend file, leading to a wait deadlock.
+ innobackupex would fail to recognize MariaDB 5.2 and MariaDB
5.3</description>
</patchinfo>
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
