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
|
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)
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