[MDEV-16107] Stale FRM in federated client Created: 2018-05-07  Updated: 2018-06-11  Resolved: 2018-06-11

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Federated
Affects Version/s: 10.0, 10.1, 10.3.6, 10.2, 10.3
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Aleksey Midenkov Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

Reproduce

install soname 'ha_federatedx';
 
create or replace table t1 (x int);
--replace_result $MASTER_MYPORT MASTER_MYPORT
eval create or replace table tf engine=FEDERATED connection='mysql://root@127.0.0.1:$MASTER_MYPORT/test/t1';
create or replace table t1 (x varchar(255));
insert into tf values ("hello");
 
drop database test;
create database test;
uninstall soname 'ha_federatedx';

Result

mysqltest: At line 7: query 'insert into tf values ("hello")' failed: 1366: Incorrect integer value: 'hello' for column 'x' at row 1

Expected

No error.

Reproduce 2

then

insert into t1 values ("hello");
select * from tf;

Result 2

+------+
| x    |
+------+
|    0 |
+------+

Expected 2.

"hello" returned.

Notes

FRM discrepancy is allowed between server and client.



 Comments   
Comment by Elena Stepanova [ 2018-05-07 ]

I'll leave it to serg to decide what to do with it. Technically, it is of course easily reproducible, but I can't imagine how it can be any different. Re-discover a table on every read or write?

Comment by Sergei Golubchik [ 2018-06-11 ]

This is expected behavior. FederatedX engine does not support automatic table discovery, so it's up to the user to ensure that the table definition is correct.

Generated at Thu Feb 08 08:26:25 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.