Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3
-
None
-
None
Description
source include/federated.inc;
|
source have_federatedx.inc;
|
|
|
connection slave; |
CREATE TABLE federated.t1 (pk INT NOT NULL PRIMARY KEY, a INT); |
INSERT INTO federated.t1 VALUES (1,1),(5,5),(9,9); |
|
|
connection master; |
--replace_result $SLAVE_MYPORT SLAVE_PORT
|
eval CREATE TABLE federated.t1 (pk INT NOT NULL PRIMARY KEY, a INT) |
ENGINE=FEDERATED
|
CONNECTION='mysql://root@127.0.0.1:$SLAVE_MYPORT/federated/t1'; |
|
|
|
|
DELETE a FROM federated.t1 a, federated.t1 b WHERE a.pk = 5 AND b.pk > 0; |
|
|
--echo # BUG: pk=5 should be gone, it is still here
|
SELECT * FROM federated.t1 ORDER BY pk; |
The reason so far is how ha_federatedx works with position(): it requires cursor to be still open to the moment of call:
join_read_const() calls ha_index_read_idx_map() which calls ha_index_end() immediately
ha_index_end() "closes the cursor": in fact, calls mysql_free_result.
ha_federatedx::position() finds that no record is allocated and fills a rowid buffer with zeroes.
Consequently, a later ha_rnd_pos() locates a record by the all-zero rowid and returns HA_ERR_END_OF_FILE, which is silently skipped.
Attachments
Issue Links
- relates to
-
MDEV-41216 ha_tina (CSV) deletes wrong records
-
- Open
-
-
MDEV-30469 Support ORDER BY and LIMIT for multi-table DELETE, index hints for single-table DELETE.
-
- Closed
-