Merge lp://staging/~sergei.glushchenko/percona-xtrabackup/2.1-xb-bug1240352 into lp://staging/percona-xtrabackup/2.1
Proposed by
Sergei Glushchenko
Status: | Work in progress |
---|---|
Proposed branch: | lp://staging/~sergei.glushchenko/percona-xtrabackup/2.1-xb-bug1240352 |
Merge into: | lp://staging/percona-xtrabackup/2.1 |
Diff against target: |
11 lines (+1/-0) 1 file modified
test/inc/ib_part.sh (+1/-0) |
To merge this branch: | bzr merge lp://staging/~sergei.glushchenko/percona-xtrabackup/2.1-xb-bug1240352 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alexey Kopytov (community) | Needs Fixing | ||
Review via email: mp+236339@code.staging.launchpad.net |
Description of the change
http://
t/ib_part_
Looks like there is another regression in kill_long_selects.
To post a comment you must log in.
Unmerged revisions
- 766. By Sergei Glushchenko
-
Bug 1240352: Sporadic t/ib_part_
include_ stream. sh failures in Jenkins Test fails with checksum = 0 before backup and checksum != 0 after
restore. Checksum value of zero indicates that data haven't made it
to the table yet. Since table is MyISAM, it can be effect of
concurrent inserts for example.The fix is to FLUSH TABLES in order to make sure all data are
written into the table.
Sergei,
I don't buy the explanation for failures, because:
1. For MyISAM tables data is guaranteed to be flushed after each INSERT.
2. Even if that wasn't the case, CHECKSUM TABLE works at the SQL level rather than on the filesystem one. Which means as long as there is some data from the server perspective, CHECKSUM TABLE should return a non-zero value.
So the reason for failures seems to be something else?