Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
10.4(EOL)
Description
CREATE TABLE t1 (b TEXT, UNIQUE(b)) ENGINE=MyISAM; |
INSERT IGNORE INTO t1 VALUES ('a'),('a'),('c'),('d'),('e'),('f'),('g'),('h'),('i'),('j'),('k'); |
|
|
# Cleanup
|
DROP TABLE t1; |
Reproducible on 10.4.
Not applicable to 10.3.
On 10.5+ it was fixed by this commit:
Author: Sergei Golubchik <serg@mariadb.org>
|
Date: Sun Apr 12 18:09:09 2020 +0200
|
|
|
MDEV-22218 InnoDB: Failing assertion: node->pcur->rel_pos == BTR_PCUR_ON upon LOAD DATA with NO_BACKSLASH_ESCAPES in SQL_MODE and unique blob in table
|
|
`inited == NONE` at the initialization time does not always mean
|
that it'll be `NONE` later, at the execution time. Use a more complex
|
caller-specific logic to decide whether to create a cloned lookup handler.
|
|
Besides LOAD (as in the original bug report) make sure that all
|
prepare_for_insert() invocations are covered by tests. Add tests for
|
CREATE ... SELECT, multi-UPDATE, and multi-DELETE.
|
|
Don't enable write cache with long uniques.
|
The problem could be considered minor, as it only affects not-the-latest-major 10.4, but it causes lots of unavoidable test failures and can easily mask real corruption issues.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
{code:sql}
CREATE TABLE t1 (b TEXT, UNIQUE(b)) ENGINE=MyISAM; INSERT IGNORE INTO t1 VALUES ('a'),('a'),('c'),('d'),('e'),('f'),('g'),('h'),('i'),('j'),('k'); # Cleanup DROP TABLE t1; {code} Reproducible on 10.4. On 10.5+ it was fixed by this commit: {noformat} Author: Sergei Golubchik <serg@mariadb.org> Date: Sun Apr 12 18:09:09 2020 +0200 `inited == NONE` at the initialization time does not always mean that it'll be `NONE` later, at the execution time. Use a more complex caller-specific logic to decide whether to create a cloned lookup handler. Besides LOAD (as in the original bug report) make sure that all prepare_for_insert() invocations are covered by tests. Add tests for CREATE ... SELECT, multi-UPDATE, and multi-DELETE. Don't enable write cache with long uniques. {noformat} The problem could be considered minor, as it only affects not-the-latest-major 10.4, but it causes lots of unavoidable test failures and can easily mask real corruption issues. |
{code:sql}
CREATE TABLE t1 (b TEXT, UNIQUE(b)) ENGINE=MyISAM; INSERT IGNORE INTO t1 VALUES ('a'),('a'),('c'),('d'),('e'),('f'),('g'),('h'),('i'),('j'),('k'); # Cleanup DROP TABLE t1; {code} Reproducible on 10.4. Not applicable to 10.3. On 10.5+ it was fixed by this commit: {noformat} Author: Sergei Golubchik <serg@mariadb.org> Date: Sun Apr 12 18:09:09 2020 +0200 `inited == NONE` at the initialization time does not always mean that it'll be `NONE` later, at the execution time. Use a more complex caller-specific logic to decide whether to create a cloned lookup handler. Besides LOAD (as in the original bug report) make sure that all prepare_for_insert() invocations are covered by tests. Add tests for CREATE ... SELECT, multi-UPDATE, and multi-DELETE. Don't enable write cache with long uniques. {noformat} The problem could be considered minor, as it only affects not-the-latest-major 10.4, but it causes lots of unavoidable test failures and can easily mask real corruption issues. |
| Workflow | MariaDB v3 [ 119470 ] | MariaDB v4 [ 142620 ] |
| Assignee | Sachin Setiya [ sachin.setiya.007 ] | Sergei Golubchik [ serg ] |
10.4 is EOL, besides I cannot reproduce it on the last 10.4 build which I have.
| Fix Version/s | N/A [ 14700 ] | |
| Fix Version/s | 10.4(EOL) [ 22408 ] | |
| Resolution | Cannot Reproduce [ 5 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
serg: Your commit is mentioned in the context of how-to-fix, so I've reassigned.