[Maria-discuss] myisam_use_mmap unstable in MariaDB 10.0.x
historical: http://lists.mysql.com/mysql/226361 after it turned out to be stable in 2013/2014 upgrade to MariaDB 10.0.17 yesterday and the logs started with table corrupt, table not closed properly and so on for tables which where not only read this time not with 'mysqld got signal 11' but only corrupted MyISAM files and after disable 'myisam_use_mmap' all is clean and stable over hours BTW a 'repair table' don't delete the TMM file leading in a 'optimize table' later failing until you delete the file manually from disk __ this configuration is unchanged for years and so my only conclusion is that Oracle managed to kill the feature again, this is also confirmed for Percona Server 5.6 where even queries fail confirmed from another sysadmin which found out that playing with my settings leaded to problems while here MariaDB 5.5.x was in use and hence no troubles - given that 'myisam_use_mmap' is borked at MariaDB 10.x and Percona 5.6 it's likely a backport from MySQL 5.6 delay-key-write = ALL concurrent_insert = 2 open-files-limit= 75 myisam-recover-options = FORCE myisam_use_mmap = 0 wait_timeout= 300 interactive_timeout = 300 max_allowed_packet = 200M max_connections = 500 max_tmp_tables = 150 max_connect_errors = 250 max_delayed_threads = 32 flush_time = 0 query_cache_limit = 256K query_cache_min_res_unit= 1K query_cache_size= 1280M query_cache_type= 1 table_cache = 1 table_definition_cache = 1 thread_cache_size = 400 tmp_table_size = 256M max_heap_table_size = 256M key_buffer_size = 256M sort_buffer_size= 256K myisam_sort_buffer_size = 15M join_buffer_size= 1M preload_buffer_size = 128K read_buffer_size= 128K read_rnd_buffer_size= 128K signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
[Maria-discuss] Giving up on dynamic columns
I discovered this showstopper on Friday while working with real data in development of a new app. I managed to narrow it down today and filed the bug report. https://mariadb.atlassian.net/browse/MDEV-7650 Looks like Maria saves an illegally formatted dyncol string if a dynamic column is longer than 64kB and is not alphabetically last by name among the dynamic column in the blob. Tbh, even is this were fixed tomorrow so I could proceed with my work, I'm not sure I would use dyncols. My confidence in the feature has been shaken. It's a pity because the Active Record ORM extension I wrote was working. Tom ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Giving up on dynamic columns
Hi Tom, On 01.03.2015 22:38, Tom Worster wrote: I discovered this showstopper on Friday while working with real data in development of a new app. I managed to narrow it down today and filed the bug report. https://mariadb.atlassian.net/browse/MDEV-7650 Looks like Maria saves an illegally formatted dyncol string if a dynamic column is longer than 64kB and is not alphabetically last by name among the dynamic column in the blob. Please note that regardless any particular feature, an application working with real data should either check for warnings which happen upon DML -- in your case, INSERTs produce Data truncated for column 'dcols', -- or, better still, set a strict sql_mode which will convert these warnings to errors, so the illegal data could never be inserted in the first place. Regards, Elena Tbh, even is this were fixed tomorrow so I could proceed with my work, I'm not sure I would use dyncols. My confidence in the feature has been shaken. It's a pity because the Active Record ORM extension I wrote was working. Tom ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Giving up on dynamic columns
who is truncating columns?
On 3/1/15, 3:27 PM, Sergei Golubchik s...@mariadb.org wrote:
Hi, Tom!
On Mar 01, Tom Worster wrote:
I discovered this showstopper on Friday while working with real data in
development of a new app. I managed to narrow it down today and filed
the
bug report.
https://mariadb.atlassian.net/browse/MDEV-7650
Looks like Maria saves an illegally formatted dyncol string if a dynamic
column is longer than 64kB and is not alphabetically last by name among
the
dynamic column in the blob.
Tbh, even is this were fixed tomorrow so I could proceed with my work,
I'm
not sure I would use dyncols. My confidence in the feature has been
shaken.
It's a pity because the Active Record ORM extension I wrote was working.
You could've paid attention to warnings from your test case:
===
MariaDB [test] insert into t (a, b, dcols) values (1, 'two',
column_create('one', 1, 'css', @txt));
Query OK, 1 row affected, 1 warning (0.00 sec)
Warning (Code 1265): Data truncated for column 'dcols' at row 1
===
Indeed, blob size is limited by 64K. Another test case for your bug is:
===
MariaDB [test] select length(column_create('one', 1, 'txt', @txt));
+--+
| length(column_create('one', 1, 'css', @txt)) |
+--+
|65563 |
+--+
1 row in set (0.00 sec)
MariaDB [test] select column_check(left(column_create('one', 1, 'txt',
@txt), 65535));
+-+
| column_check(left(column_create('one', 1, 'txt', @txt), 65535)) |
+-+
| 1 |
+-+
1 row in set (0.00 sec)
MariaDB [test] select column_check(left(column_create('one', 1, 'css',
@txt), 65535));
+-+
| column_check(left(column_create('one', 1, 'css', @txt), 65535)) |
+-+
| 0 |
+-+
1 row in set (0.00 sec)
===
So the bug is that column_check() doesn't always detects that the dyncol
was truncated.
Either way, even if column_check() returns 1, you probably shouldn't
use truncated dynamic columns in your application :)
Use LONGBLOB instead.
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Giving up on dynamic columns
so it turns out the problem is my incompetence. i thought blob allowed long values. i've been using mysql since 3.something and i still don't know much about its abundance of types. i retract my comments and crawl back into my hole. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
