Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL)
Description
CREATE TABLE t1 (a INT, b CHAR(8), UNIQUE INDEX(a)) ENGINE=RocksDB; |
INSERT INTO t1 (a,b) VALUES (1,'foo'),(2,'bar'); |
UPDATE t1 SET a=a+100; |
SELECT * FROM t1; |
|
Actual result |
MariaDB [test]> SELECT * FROM t1;
|
+------+------+
|
| a | b |
|
+------+------+
|
| 101 | foo |
|
| 2 | bar |
|
+------+------+
|
2 rows in set (0.00 sec)
|
|
Expected result |
MariaDB [test]> SELECT * FROM t1;
|
+------+------+
|
| a | b |
|
+------+------+
|
| 101 | foo |
|
| 102 | bar |
|
+------+------+
|
2 rows in set (0.00 sec)
|
It is a recent regression, apparently from the last merge or post-merge changes, I didn't search for the exact commit.
Attachments
Activity
The same happens on a recent upstream MyRocks:
CREATE TABLE t1 (a INT, b CHAR(8), UNIQUE INDEX(a)) ENGINE=RocksDB;
|
INSERT INTO t1 (a,b) VALUES (1,'foo'),(2,'bar');
|
SELECT * FROM t1;
|
a b
|
1 foo
|
2 bar
|
UPDATE t1 SET a=a+100;
|
SELECT * FROM t1;
|
a b
|
101 foo
|
2 bar
|
drop table t1;
|
rocksdb._a 'write_prepared' [ pass ] 407
|
commit 6a82972dfc23405406be511161ddd71e58c30eaa
|
Author: Sergei Petrunia <psergey@askmonty.org>
|
Date: Mon May 7 20:03:54 2018 +0300
|
|
|
Issue #809: Wrong query result with bloom filters
|
|
In reverse-ordered column families, if one wants to start reading at the
|
logical end of the index, they should Seek() to a key value that is not
|
covered by the index. This may (and typically does) prevent use of a bloom
|
filter.
|
The calls to setup_scan_iterator() that are made for index and table scan
|
didn't take this into account and passed eq_cond_len=INDEX_NUMBER_SIZE.
|
Fixed them to compute and pass correct eq_cond_len.
|
|
Also, removed an incorrect assert in ha_rocksdb::setup_iterator_bounds.
|
|
Happens on the current upstream, too.
Author: Volodymyr Verovkin <verjovkin@devvm760.prn3.facebook.com>
|
Date: Fri May 11 21:17:55 2018 -0700
|
|
|
Fixed main.mysqld--help-notwin test. To run it, please include --perfschema --release options.
|
INSERT INTO t1 (a,b) VALUES (1,'foo'),(2,'bar');
|
SELECT * FROM t1;
|
a b
|
1 foo
|
2 bar
|
UPDATE t1 SET a=a+100;
|
SELECT * FROM t1;
|
a b
|
101 foo
|
2 bar
|
drop table t1;
|
rocksdb._a 'write_prepared' [ pass ] 15
|
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 10.2.15 [ 23006 ] | |
| Fix Version/s | 10.3.7 [ 23005 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
We have an understanding of the issue that is shared with the upstream devs.
I've pushed my fix (upstream are still considering other options). If they chose to fix it in a different way, we will eventually switch to using their fix. (codewise it's trivial so there shouldn't be any surprises)
| Workflow | MariaDB v3 [ 87186 ] | MariaDB v4 [ 154351 ] |
The same behavior can be observed on the upstream we have merged from
CREATE TABLE t1 (a INT, b CHAR(8), UNIQUE INDEX(a)) ENGINE=RocksDB;INSERT INTO t1 (a,b) VALUES (1,'foo'),(2,'bar');SELECT * FROM t1;a b1 foo2 barUPDATE t1 SET a=a+100;SELECT * FROM t1;a b101 foo2 bardrop table t1;rocksdb._a [ pass ] 231commit f8f364b47f2784f16b401f27658f1c16eaf348ecAuthor: Jay Edgar <jkedgar@fb.com>Date: Tue Oct 17 15:19:31 2017 -0700Add a hashed, hierarchical, wheel timer implementation