Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3.1
Description
The purpose of MDEV-12288 is to reset the DB_TRX_ID column when the history is being removed. This is not taking place:
--source include/have_innodb.inc
|
CREATE TABLE t1(a INT PRIMARY KEY, b INT NOT NULL) ENGINE=InnoDB;
|
INSERT INTO t1 VALUES(1,2),(3,4);
|
UPDATE t1 SET b=-3 WHERE a=3;
|
# Initiate a full purge, which should reset all DB_TRX_ID.
|
SET GLOBAL innodb_fast_shutdown=0;
|
--source include/shutdown_mysqld.inc
|
After running this test, the t1.ibd file page 3 will contain nonzero DB_TRX_ID values.
Attachments
Issue Links
- blocks
-
-
- Closed
-
- causes
-
-
- Closed
-
-
-
- Closed
-
- is caused by
-
MDEV-12288 Reset DB_TRX_ID when the history is removed, to speed up MVCC
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue is caused by |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Assignee | Marko Mäkelä [ marko ] | Jan Lindström [ jplindst ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
jplindst, please run innodb.innodb_bug14147491 in the branch. It seems that some follow-up fix for MDEV-12253 is needed, so that the server will not crash when flagging a page corrupted.
I pushed a follow-up adjustment for some test failures, including a workaround for the innodb.innodb_14147491 failure.
It looks like some code changes will be necessary, because the system columns in two records are not being reset in innodb.table_flags.
It turned out that some undo log records were being omitted from the purge queue.
Because of this, among other things, the history for the SYS_DATAFILES and SYS_FOREIGN_COLS records in SYS_TABLES was not being reset. The records were being skipped, even though the records for SYS_TABLESPACES or SYS_FOREIGN (by the same transactions) were buffered for purge.
Last commit ok to push, the first one still has FIXME comment, has the code review done ?
| Link |
This issue relates to |
There is one outstanding FIXME in the first commit: Carefully review the code to determine if the comment that we are removing from trx_purge_free_segment() is bogus, and if it is actually safe to remove the TRX_UNDO_DEL_MARKS field.
I did not observe a test failure related to this, but I do need to review this. We definitely do not want to have purge accessing a stale or freed undo log page.
All other FIXME comments have been addressed in subsequent commits to bb-10.3-marko. I will squash these commits once bb-10.3-marko is green.
The final push to 10.3 will consist of two commits:
- the first 3 commits squashed together (excluding the innodb.innodb_bug14147491 changes)
- innodb.innodb_bug14147491 and encryption test workarounds for
MDEV-13542Crashing on a corrupted page is unhelpful
| Assignee | Jan Lindström [ jplindst ] | Marko Mäkelä [ marko ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| issue.field.resolutiondate | 2017-08-16 10:12:56.0 | 2017-08-16 10:12:56.652 |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Link |
This issue relates to |
Note for benchmarks: implemented in commit 92f9be4, reference should be the commit immediately before f4b379d. Workload shall include read-only and read/write TRX. Possibly some queries using secondary indexes.
| Link |
This issue causes |
| Link |
This issue blocks |
| Link |
This issue causes |
| Workflow | MariaDB v3 [ 82101 ] | MariaDB v4 [ 152626 ] |
bb-10.3-marko