| Bug #94541 | Assertion on import via Transportable Tablespace | ||
|---|---|---|---|
| Submitted: | 4 Mar 2019 9:32 | Modified: | 4 Sep 2019 14:41 |
| Reporter: | Daniël van Eeden (OCA) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
| Version: | 5.7.25 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[4 Mar 2019 9:32]
Daniël van Eeden
[6 Mar 2019 14:15]
MySQL Verification Team
Hi Daniel, Thank you for your bug report. I see exactly where the assertion happens, but I can not verify the bug without repeating it. You see, that assertion can happen due to a large variety of causes, so we can not detect which is the one that happened in your case. Hence, we will need a feedback from you. While we are waiting on your feedback, I will enquire whether it would be possible to break that assertion into a code that will provide the error message for all possible causes which might cause that assertion. I hope that you will agree with me. Meanwhile ..... Can you provide us with a table definition and contents (I guess there were no rows) and with a tablespace. You can also provide us with a dump of the tablespace, without uploading a tablespace to our sftp server. Hence, you can use either to upload what is necessary for us in order to repeat the problem or, if there is not much info, to provide all info in a hidden comment. To upload table and tablespace, you can use "Files" tab from this interface. If data are too large, you can use sftp command, as described in "Files" tab. While you are preparing what we need, I shall initiate a discussion on whether it would be possible to handle this case without killing the server, but, instead, to provide a verbose error message on the cause of why the imported data is considered to be invalid. I am sure that you understood my basic plan on this problem.
[7 Mar 2019 14:01]
MySQL Verification Team
Hi Daniel, We had a discussion on this topic and concluded that this is a bug that requires changes in our code. So, right now, we do not need any feedback from you. Verified as reported.
[4 Sep 2019 14:21]
Daniel Price
Posted by developer:
commit 1d6bcf7fe93a8d3c669c2237532761acf9b873cd
Author: Sachin Agarwal <sachin.z.agarwal@oracle.com>
Date: Wed Sep 4 13:05:58 2019 +0530
Bug#29454828 ASSERTION ON IMPORT VIA TRANSPORTABLE TABLESPACE
Problem:
If we flush a table for EXPORT which has delete-marked rows.
During flush, PageConverter read the pages and try to purge
delete-marked records, only if it is possible to do so without
re-organising the B+tree otherwise increase m_n_purge_failed counter
in index stats.
Later during IMPORT tablespace, we check m_n_purge_failed counter
and purge any delete-marked records that couldn't be purged during
the page conversion phase.
To purge all delete-marked records, IndexPurge::garbage_collect()
iterate over all the record, if a record is delete-marked then purge
that record.
If any page is corrupted and we position the cursor to that page
then we hit an assert :
ut_a(btr_page_get_prev(next_page, mtr) ==
btr_pcur_get_block(cursor)->page.id.page_no())
Instead of hitting any assert, we should terminate import tablespace
operation and throw an error.
Fix:
Converted this assert check to if condition check for import
operation. If a page is corrupted then we terminate import
tablespace operation and throw an error.
RB: 22895
Reviewed by: Mayank Prasad <mayank.prasad@oracle.com>
[4 Sep 2019 14:41]
Daniel Price
Posted by developer: Fixed as of the upcoming 5.7.29, 8.0.19 releases, and here's the changelog entry: A tablespace import operation raised an assertion when the cursor was positioned on a corrupted page while purging delete-marked records. Instead of asserting when encountering a corrupted page, the import operation is now terminated and an error is reported.
[4 Sep 2019 15:47]
MySQL Verification Team
Thank you, Daniel ......
