Re: Re: signal handling in mysql cli
Hello Sebastein, On 2014-12-03 17:25, Sebastien FLAESCH wrote: Hi all, I have a similar question regarding KILL QUERY usage: We have a C client program using libmysqlclient.so, it is a single-threaded program. When running a long query, how can I send the KILL QUERY command when a SIGINT (CTRL-C) is caught? (of course we implement a signal handler, so we keep the control) = Is is safe to establish a new connection to the server in the signal handler, using mysql_init() + mysql_real_connect(), and execute the KILL QUERY with the mysql thread id I got from the initial mysql_init() / mysql_real_connect()? I made some tests, and it seems to work fine, the long query returns SQL error -1317: Query execution was interrupted (which is expected) We want to support SQL interruption properly, so please someone from the dev team, give me a clear answer... I don't want to use a side effect or undocumented feature. Issuing KILL QUERY from a separate connection is the way to do it. We do not currently have any CAPI abort function - introducing such functionality would require changes on the protocol level. Doing all this stuff in a signal handler is certainly risky... no? Whether it is safe to do I/O extensive work inside a signal handler is another topic, not related to MySQL client library. Depends on your particular case and how careful you are about writing handler code which can be executed at any time. One safe option is that signal handler only sets a flag informing about the signal and then either the main logic of your application detects the flag and performs KILL operation, or you have a separate dedicated thread to do this job. Rafal (from Connectors/C team @ MySQL) I could not find the information in the documentation (mysql_real_connect). I wish there would be an API like mysql_cancel_query(), similar to Oracle's OCI OCIBreak(). Thanks! Seb On 12/02/2014 05:13 PM, walter harms wrote: hi list, when i use CTRL-C to break a query that works fine in interactive mode. mysql select sleep(10) ; ^CCtrl-C -- sending KILL QUERY 24289 to server ... Ctrl-C -- query aborted. +---+ | sleep(10) | +---+ +---+ 1 row in set (0.86 sec) but when i use the noninteractive mode timeout 5 mysql -BAN -e select now(); select sleep (100) ; select now() i looks like that but show full processlist; shows otherwise and that is true as a list of long running querys showed. Is there a way to make it behave like the interactive version ? Now it is a bit confusing for everyone. re, wh -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Fwd: Re: libmysqlclient so version
Forwarding my reply here, as it might be interesting to other people too. Original Message Subject: Re: libmysqlclient so version Date: Mon, 05 Aug 2013 14:10:28 +0200 From: rafal somla rafal.so...@oracle.com Organization: Oracle Corporation To: Sebastien FLAESCH s...@4js.com Hello Sebastien, Thank you for your interest in our latest MySQL server release. On 07/31/2013 01:03 PM, Sunanda Menon wrote: * The C API libmysqlclient shared-library .so files now have version 18.1.0 (up from version 18.0.0 used in MySQL 5.5). (Bug #16809055) What impact has this change regarding backward compatibility with existing C programs linked to older 5.6 libmysqlclient.so libs and what is the general policy regarding the backward compatibility for this library - where can we find clear statements in the doc? Does it make sense to change the .so version in a bug fix release, when the 5.6 was already releases as GA? We are providing database drivers for MySQL in our development tool. We have a C shared library linked to libmysqlclient.so, and we have to link it with the correct 5.6 library version. What solution would you recommend, if you change the .so version number in MySQL 5.6 upgrade / bug fix releases? Although we changed the minor library version in 5.6.13, it should be fully backward compatible with previous versions and code using the library should work without any problems. In particular, any code which links against libmysqlclient.so depends on libmysqlclient.so.18 (note that the minor version number is not present in the soname). Version 18.1.0 of the library installs with a symbolic link libmysqlclient.so.18 - libmysqlclient.so.18.1.0. Thus we expect all applications to work as before after upgrading to MySQL 5.6.13. Please let us know if it does not work for you. With Best Regards, Rafal Somla, Senior Software Developer @ MySQL/Oracle -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: libmysqlclient so version
Hello again! On 2013-08-05 15:07, Sebastien FLAESCH wrote: Hello Rafal and thank you for you answer. Note I sent a similar mail in the mailing list. So I think you should also answer in the mailing list too. I understand that it should be ok regarding libmysqlclient.so.18.1.0. $ ldd -r /home/sf/genero/devel/fgl/fgl/opt/fgl/dbdrivers/dbmmys55x.so libmysqlclient.so.18 = /opt3/dbs/mys/5.6.10/lib/libmysqlclient.so.18 (0xb7298000) If I may ask you something that would help me a lot: We have an internal debate, where some argue that we could have a unique binary linked to libmysqlclient.so, that could work for all MySQL versions, for example for all 5.x versions. While it appears that 5.5.x and 5.6.x libraries are compatible (since the major version number (18) of the lib did not change), my instinct is that we should produce one specific binary for each major MySQL version we want to support (i.e 4.1.x, 5.0.x, 5.1.x, 5.4.x, 5.5.x, 5.6.x) ... We need a clear rule...!! For example with Oracle database, we have a binary for each major version of Oracle (9.0.x, 9.2.x, 10.1.x, 10.2.x, 11.1.x, 11.2.x, 12.1.x) I asked for a clear compatibility statement in the doc... If you could state that it's STRONGLY recommended to link C binaries with a libmysqlclient.so.num version for each major MySQL, it would help me to define a clear rule for our product... In general we strive to keep the library backward compatible - as long as the major version of the library is the same, it should be safe to use the library with old applications. You should care about minor version only if you want to use some new API calls introduced in later release of the library. I think the best practice would be to check which release of the library is used at runtime (using mysql_client_version() API call) and then either make use of new features conditional on this version check or error-out if library is not recent enough The major version of libmysqlclient library is not tied to a particular version of MySQL server. It rather reflects changes in the C API itself. Thus it is quite possible that two different versions of MySQL server offer the same version 18.X of the client library with the same functionality, but perhaps the newer version contains bug fixes or improvements in the implementation of this functionality. Thus I do not see a need to produce new version of binaries for each new released version of MySQL server. Rather, you should re-compile your applications only if either: a) you want to use new C API features introduced in the new release, or b) we introduce incompatible change in C API and thus increase its major version number (e.g from 18.X to 19.0). In that case new binaries will look for libmysqlclient.so.19 while old ones will still use libmysqlclient.so.18. Note that even without re-compiling your apps, if you upgrade your MySQL installation then new version of libmysqlcient.so will be installed on your system and picked up by the dynamic linker. So your application will take benefit of bug fixes and other improvements in C API implementation. Best Regards, Rafal Best regards, Sebastien FLAESCH Four JS Development Tools On 08/05/2013 02:10 PM, rafal somla wrote: Hello Sebastien, Thank you for your interest in our latest MySQL server release. On 07/31/2013 01:03 PM, Sunanda Menon wrote: * The C API libmysqlclient shared-library .so files now have version 18.1.0 (up from version 18.0.0 used in MySQL 5.5). (Bug #16809055) What impact has this change regarding backward compatibility with existing C programs linked to older 5.6 libmysqlclient.so libs and what is the general policy regarding the backward compatibility for this library - where can we find clear statements in the doc? Does it make sense to change the .so version in a bug fix release, when the 5.6 was already releases as GA? We are providing database drivers for MySQL in our development tool. We have a C shared library linked to libmysqlclient.so, and we have to link it with the correct 5.6 library version. What solution would you recommend, if you change the .so version number in MySQL 5.6 upgrade / bug fix releases? Although we changed the minor library version in 5.6.13, it should be fully backward compatible with previous versions and code using the library should work without any problems. In particular, any code which links against libmysqlclient.so depends on libmysqlclient.so.18 (note that the minor version number is not present in the soname). Version 18.1.0 of the library installs with a symbolic link libmysqlclient.so.18 - libmysqlclient.so.18.1.0. Thus we expect all applications to work as before after upgrading to MySQL 5.6.13. Please let us know if it does not work for you. With Best Regards, Rafal Somla, Senior Software Developer @ MySQL/Oracle -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
How to grant privileges using REVOKE statement
Hi All! Here is a funny thing I come across when investigating our privilege control system. Consider the following situation: mysql GRANT ALL ON `%o`.* TO rafal; mysql GRANT SELECT ON foo.* TO rafal; The intention is that rafal has all privileges for all objects in databases whose name ends with 'o' but he has read-only access to the tables in the 'foo' database. Now imagine DBA decides that rafal should no longer be able to see the data inside the foo database. Then he might issue command mysql REVOKE ALL ON foo.* FROM rafal; and... tada! rafal has all rights to all tables inside database 'foo'. The reason is that REVOKE command, when it sees that all rights have been revoked, removes the corresponding entry in the privilege table inside mysql database (mysql.db in that case). But removing such entry doesn't mean that all rights will be taken away, since, as this example illustrates, some other entry can apply after removing that one and in fact give more rights than before! A solution would be to not remove any entries when REVOKE is executed - just clear the corresponding flags in the existing entry. Best, Rafal -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
