TIME field not restored with the correct value (5.5)
Bug #1312446 reported by
Frederic Descamps
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Data Recovery Tool for InnoDB |
New
|
Undecided
|
Unassigned |
Bug Description
When a TIME field is extracted by constraints_parser, the dumped value is not correct.
For example instead of "09:00:00", "01:00:00" is returned and for "09:10:00", "01:16:40" is returned.
This happen when field->
The field definition is:
type: FT_TIME,
fixed_length: 3,
time_precision: 0,
can_be_null: TRUE
To post a comment you must log in.
I tried to reproduce this on a very simple table:
+----+----------+
| id | gne |
+----+----------+
| 1 | 10:01:20 |
| 2 | 00:02:29 |
| 3 | 10:09:00 |
| 4 | 10:09:00 |
| 5 | 01:00:00 |
| 6 | 09:00:00 |
+----+----------+
Then after doing the full process, the dump file is:
-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (6 6)
000000001B03 83000001350110 fred 1 "03:48:40"
000000001B05 85000001B00110 fred 2 "00:03:49"
000000001B0A 87000001770110 fred 3 "04:01:40"
000000001B0B 88000001E60110 fred 4 "04:01:40"
000000001B0D 8A000001750110 fred 5 "02:46:40"
000000001B0E 8B000001780110 fred 6 "01:00:00"
-- Page id: 3, Found records: 6, Lost records: NO, Leaf page: YES
and dates are incorrect.
After applying the patch and running constraints_parser again, the dump file is correct:
-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (6 6)
000000001B03 83000001350110 fred 1 "10:01:20"
000000001B05 85000001B00110 fred 2 "00:02:29"
000000001B0A 87000001770110 fred 3 "10:09:00"
000000001B0B 88000001E60110 fred 4 "10:09:00"
000000001B0D 8A000001750110 fred 5 "01:00:00"
000000001B0E 8B000001780110 fred 6 "09:00:00"
-- Page id: 3, Found records: 6, Lost records: NO, Leaf page: YES