It might be a good idea to mirror the refGene table to a machine of yours (as described above).
That way you could use it in order to investigate why mariadb is hanging here.

Since refGene is a widely used database in bioinformatics I assume that the faulty data-source will be corrected very soon.

>> It might be a good idea to mirror the refGene table to a machine of yours (as described above).
>> That way you could use it in order to investigate why mariadb is hanging here.

I did it from the start, and I observed the behavior that you described, but the problem went away after I changed the permissions on the table and ran mysql_upgrade.
Which reminds me that I asked you about mysql_upgrade, but not about permissions: if you copy the database the same way you suggested, via sudo rsync .. , could it be that you didn't change the owner of the copied database to 'mysql' (which is probably the account used for your mariadb server) afterwards?

You're right, actually I hadn't changed permissions of the files which is probably why repairing with mysql_upgrade hasn't worked out for me

Still I think that it might be a nice improvement of the database system if it would return with an error-message instead of hanging.
The log-file tells me that a problem with the table has been recognized correctly, so it might also be possible to catch that error, output an error-message and break the action.

The faulty table has been corrected on the remote server in the meantime.

Thanks a lot for your very nice support !!!

I agree, it was confusing, and it still seems to be a bug, although not critical since there is an external reason and a good workaround.
Actually, I see 2 problems here.

1. When you attempt to use this database, what looks like a hanging is actually an endless loop – we can see that the error log keeps getting new messages
130405 16:37:09 [ERROR] mysqld: Table './hg19/refGene' is marked as crashed and should be repaired
130405 16:37:09 [Warning] Checking table: './hg19/refGene'
130405 16:37:09 [ERROR] mysqld: Table './hg19/refGene' is marked as crashed and should be repaired
130405 16:37:09 [Warning] Checking table: './hg19/refGene'

server uses as much cpu as it can get
8129 elenst 20 0 1189m 331m 7520 S 100 4.2 0:22.89 mysqld

and memory footprint also grows
8129 elenst 20 0 1253m 405m 7520 S 100 5.1 2:20.42 mysqld

The process is in checking table stage
MariaDB [test]> show processlist;
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
2 rows in set (0.00 sec)

Obviously all of that shouldn't be happening, the server doesn't need to loop over the broken table. Instead, it should check it once and (at least) throw the error which it produces if we forcefully kill the thread checking the table:

130405 16:42:57 [Warning] Checking table: './hg19/refGene'
130405 16:42:57 [ERROR] mysqld: Table './hg19/refGene' is marked as crashed and should be repaired
130405 16:42:57 [Warning] Checking table: './hg19/refGene'
130405 16:42:57 [Warning] Recovering table: './hg19/refGene'
130405 16:42:57 [ERROR] Couldn't repair table: hg19.refGene

2. The error message in the error log could be much clearer. The server is able to detect the reason of the problem, we can see it in the CHECK TABLE output:

MariaDB [test]> check table hg19.refGene;
--------------------------------------------------------------------------------+

--------------------------------------------------------------------------------+

--------------------------------------------------------------------------------+
3 rows in set (0.28 sec)

Errcode 13 is 'Permission denied', so it should be a good clue.

REPAIR TABLE diagnostics is not bad either:

MariaDB [test]> repair table hg19.refGene;
--------------------------------------------------------+

--------------------------------------------------------+

--------------------------------------------------------+
2 rows in set (0.00 sec)

But the error log only keeps saying "is marked as crashed and should be repaired".

To reproduce:

• create a clean database, e.g. using mysql_install_db;
• unpack the attached archive hg19.tar.gz in the datadir;
• change ownership for the hg19 folder (recursively) e.g.
  sudo chown -R root:root hg19
• start server on this datadir (not as root), default options are enough
• run mysql -uroot <connect options> hg19
• observe hanging, check error log to see it being flooded by error messages.

Not reproducible on MySQL (tried 5.5, 5.6).