Re: MySQL optimization for testing purpose
On 04/03/2018 06:15 PM, Sebastien FLAESCH wrote: On 04/03/2018 05:59 PM, Sebastien FLAESCH wrote: Hi all, Looking for some configuration tips to speed execution of our non-regression tests with MySQL. We do pure functional testing, data persistence is not critical. Our tests are not using a lot of data, but we create and drop a lot of test tables. We have concurrency tests (processes locking rows), so this feature matters. Are there some InnoDB params to enable or disable to speed up our tests? Some tests behave a bit strange, sometimes one of our test takes 1 min 30 secs, sometimes it takes only 15 seconds... In fact this tests creates and drops ~150 times the same table, having a single column using different types each time. I can clearly see that sometimes table creations are fast, but from time to time it slows down to about a second to create a table. How can this happen? Any log I could enable and provide here? Thanks in advance! Seb FYI, have tried following settings, but it did not help: innodb_stats_auto_recalc=0 innodb_file_per_table=0 innodb_stats_persistent=0 I have recreated my database after restarting the server. Server version: 8.0.4-rc-log MySQL Community Server (GPL) Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL optimization for testing purpose
On 04/03/2018 05:59 PM, Sebastien FLAESCH wrote: Hi all, Looking for some configuration tips to speed execution of our non-regression tests with MySQL. We do pure functional testing, data persistence is not critical. Our tests are not using a lot of data, but we create and drop a lot of test tables. We have concurrency tests (processes locking rows), so this feature matters. Are there some InnoDB params to enable or disable to speed up our tests? Some tests behave a bit strange, sometimes one of our test takes 1 min 30 secs, sometimes it takes only 15 seconds... In fact this tests creates and drops ~150 times the same table, having a single column using different types each time. I can clearly see that sometimes table creations are fast, but from time to time it slows down to about a second to create a table. How can this happen? Any log I could enable and provide here? Thanks in advance! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
MySQL optimization for testing purpose
Hi all, Looking for some configuration tips to speed execution of our non-regression tests with MySQL. We do pure functional testing, data persistence is not critical. Our tests are not using a lot of data, but we create and drop a lot of test tables. We have concurrency tests (processes locking rows), so this feature matters. Are there some InnoDB params to enable or disable to speed up our tests? Some tests behave a bit strange, sometimes one of our test takes 1 min 30 secs, sometimes it takes only 15 seconds... How can this happen? Any log I could enable and provide here? Thanks in advance! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL Community Server 8.0.3-rc has been released (part 1/2)
Can you please stop using C++ comments in header files designed for C programming? /opt3/dbs/mys/8.0/include/mysql.h:36:1: error: C++ style comments are not allowed in ISO C90 [-Werror] // Small extra definitions to avoid pulling in my_inttypes.h in client code. ^ /opt3/dbs/mys/8.0/include/mysql.h:36:1: error: (this will be reported only once per input file) [-Werror] In file included from /opt3/dbs/mys/8.0/include/mysql.h:68:0, from mys.c:42: /opt3/dbs/mys/8.0/include/binary_log_types.h:68:8: error: C++ style comments are not allowed in ISO C90 [-Werror] #endif // __cplusplus ^ /opt3/dbs/mys/8.0/include/binary_log_types.h:68:8: error: (this will be reported only once per input file) [-Werror] In file included from /opt3/dbs/mys/8.0/include/mysql.h:69:0, from mys.c:42: /opt3/dbs/mys/8.0/include/mem_root_fwd.h:30:9: error: C++ style comments are not allowed in ISO C90 [-Werror] #endif // MEM_ROOT_FWD_INCLUDED ^ /opt3/dbs/mys/8.0/include/mem_root_fwd.h:30:9: error: (this will be reported only once per input file) [-Werror] In file included from /opt3/dbs/mys/8.0/include/mysql.h:83:0, from mys.c:42: /opt3/dbs/mys/8.0/include/mysql_time.h:29:1: error: C++ style comments are not allowed in ISO C90 [-Werror] // Do not not pull in the server header "my_inttypes.h" from client code. ^ ... Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: kill query and prepared statements
Sorry for the spam, and thanks for you suggestion Johan! http://bugs.mysql.com/bug.php?id=84470 Seb On 01/11/2017 11:21 AM, Johan De Meersman wrote: Seb, You should log a bug at http://bugs.mysql.com - this is not a developer list. /Johan - Original Message - From: "Sebastien FLAESCH" <s...@4js.com> To: "MySql" <mysql@lists.mysql.com> Sent: Tuesday, 10 January, 2017 14:55:42 Subject: kill query and prepared statements Hi all, I have reported this problem before, but I raise it again, since I still get this problem with 5.7.17 See attached code: I want to interrupt a long running statement with CTRL-C by starting a new connect to make a KILL QUERY. I am using the same technique as the mysql client code. The difference here is that my code is using PREPARED STATEMENTS with mysql_stmt_prepare() etc. Problem: After interrupting the first query with CTRL-C, the call to mysql_stmt_close() hangs... Maybe I am missing some new connection or statement option...?!? IMPORTANT: This problem appeared in a 5.7.x, same code is working fine with 5.6(.16) Please can someone from MySQL C API team try to reproduce and confirm? Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: kill query and prepared statements
Just to be clear: This is a hint, to find the real problem, this is NOT A WORKAROUND for us! Seb On 01/10/2017 03:53 PM, Sebastien FLAESCH wrote: Investigating different API calls, to see if it makes a difference... Seems that the problem is related to the read-only cursor type option! If you comment out: unsigned long ct = (unsigned long) CURSOR_TYPE_READ_ONLY; s = mysql_stmt_attr_set(stmt, STMT_ATTR_CURSOR_TYPE, (const void *) ); Then it works ... Seb On 01/10/2017 02:55 PM, Sebastien FLAESCH wrote: Hi all, I have reported this problem before, but I raise it again, since I still get this problem with 5.7.17 See attached code: I want to interrupt a long running statement with CTRL-C by starting a new connect to make a KILL QUERY. I am using the same technique as the mysql client code. The difference here is that my code is using PREPARED STATEMENTS with mysql_stmt_prepare() etc. Problem: After interrupting the first query with CTRL-C, the call to mysql_stmt_close() hangs... Maybe I am missing some new connection or statement option...?!? IMPORTANT: This problem appeared in a 5.7.x, same code is working fine with 5.6(.16) Please can someone from MySQL C API team try to reproduce and confirm? Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: kill query and prepared statements
Investigating different API calls, to see if it makes a difference... Seems that the problem is related to the read-only cursor type option! If you comment out: unsigned long ct = (unsigned long) CURSOR_TYPE_READ_ONLY; s = mysql_stmt_attr_set(stmt, STMT_ATTR_CURSOR_TYPE, (const void *) ); Then it works ... Seb On 01/10/2017 02:55 PM, Sebastien FLAESCH wrote: Hi all, I have reported this problem before, but I raise it again, since I still get this problem with 5.7.17 See attached code: I want to interrupt a long running statement with CTRL-C by starting a new connect to make a KILL QUERY. I am using the same technique as the mysql client code. The difference here is that my code is using PREPARED STATEMENTS with mysql_stmt_prepare() etc. Problem: After interrupting the first query with CTRL-C, the call to mysql_stmt_close() hangs... Maybe I am missing some new connection or statement option...?!? IMPORTANT: This problem appeared in a 5.7.x, same code is working fine with 5.6(.16) Please can someone from MySQL C API team try to reproduce and confirm? Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
kill query and prepared statements
Hi all,
I have reported this problem before, but I raise it again, since I still get
this problem with 5.7.17
See attached code:
I want to interrupt a long running statement with CTRL-C by starting a new
connect to make a KILL QUERY.
I am using the same technique as the mysql client code.
The difference here is that my code is using PREPARED STATEMENTS with
mysql_stmt_prepare() etc.
Problem: After interrupting the first query with CTRL-C, the call to
mysql_stmt_close() hangs...
Maybe I am missing some new connection or statement option...?!?
IMPORTANT: This problem appeared in a 5.7.x, same code is working fine with
5.6(.16)
Please can someone from MySQL C API team try to reproduce and confirm?
Thanks!
Seb
#include
#include
#include
#include
#include
#include
static char * c_host = "orion";
static char * c_user = "mysuser";
static char * c_auth = "fourjs";
static intc_port = 3308;
static char * c_sock = NULL;
static char * c_dbnm = "test1";
static int executing_query;
static unsigned long thread_id;
static void kill_query(void)
{
char cmd[50];
MYSQL *h;
h = mysql_init(NULL);
if (!mysql_real_connect(h, c_host, c_user, c_auth,
c_dbnm, c_port, c_sock,
CLIENT_FOUND_ROWS)) {
fprintf(stderr, "kill_query: Could not connect (err=%d)\n", mysql_errno(h));
return;
}
sprintf(cmd, "KILL QUERY %ld", thread_id);
if (mysql_query(h, cmd) != 0) {
fprintf(stderr, "Could not execute %s.", cmd);
}
mysql_close(h);
}
static void handle_ctrlc_signal(int sig)
{
fprintf(stdout, "SIGINT caught! executing_query = %d\n", executing_query);
if (executing_query) {
executing_query = 0;
kill_query();
}
return;
}
int main(int argc, char ** argv)
{
MYSQL * conn;
MYSQL_STMT * stmt;
int i, s;
unsigned long ct = (unsigned long) CURSOR_TYPE_READ_ONLY;
const char * sqlstmt = "select benchmark(10, md5('when will it end?'))";
signal(SIGINT, handle_ctrlc_signal);
conn = mysql_init(NULL);
if (!mysql_real_connect(conn, c_host, c_user, c_auth,
c_dbnm, c_port, c_sock,
CLIENT_FOUND_ROWS)) {
fprintf(stderr, "Could not connect (err=%d)\n", mysql_errno(conn));
return -1;
}
thread_id = mysql_thread_id(conn);
fprintf(stdout, "MySQL thread ID: %ld\n", thread_id);
for (i=0; i<3; i++) {
fprintf(stdout, "\nRound %d:\n", i+1);
fprintf(stdout, "Allocating statement handle...");
stmt = mysql_stmt_init(conn);
if (stmt==NULL) {
fprintf(stderr, "Could not create statement handle (err=%d)\n", mysql_errno(conn));
return -1;
}
fprintf(stdout, " handle = %p\n", (void*) stmt);
fprintf(stdout, "Preparing statement %p ...\n", (void*) stmt);
s = mysql_stmt_prepare(stmt, sqlstmt, (unsigned long) strlen(sqlstmt));
if (s!=0) {
fprintf(stderr, "Could not prepare statement (err=%d)\n", mysql_errno(conn));
return -1;
}
fprintf(stdout, "Setting cursor type to read only for %p ...\n", (void*) stmt);
s = mysql_stmt_attr_set(stmt, STMT_ATTR_CURSOR_TYPE, (const void *) );
if (s!=0) {
fprintf(stderr, "Could not set cursor type (err=%d)\n", mysql_errno(conn));
return -1;
}
fprintf(stdout, "Executing statement %p ...\n", (void*) stmt);
executing_query = 1;
s = mysql_stmt_execute(stmt);
if (s!=0) {
if (mysql_errno(conn) == 1317) {
fprintf(stdout, "Statement interrupted by user...\n");
} else {
fprintf(stderr, "Could not execute the query (err=%d)\n", mysql_errno(conn));
return -1;
}
}
fprintf(stdout, "Closing/freeing statement handle %p ...\n", (void*) stmt);
s = mysql_stmt_close(stmt);
if (s!=0) {
fprintf(stderr, "Could not close statement handle (err=%d)\n", mysql_errno(conn));
return -1;
}
fprintf(stdout, "Round done.\n");
}
return 0;
}
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql
Re: Query interruption with MySQL 5.7 using KILL QUERY in signal handler does no more work
I did the following test: My program still uses MySQL 5.7 libmysqlclient.so, but I connect now to a 5.6.16 server. And the SQL interrupt works fine... so I suspect there is a MySQL server issue in 5.7. Seb On 07/12/2016 01:01 PM, Sebastien FLAESCH wrote: About: > B) For some reason, the program does not want to exit() - (must investigate) In fact we use prepared statements with a sequence of mysql_stmt_init, mysql_stmt_prepare, mysql_stmt_execute, mysql_stmt_fetch, ... and mysql_stmt_close. After the statement was interrupted, we try to free the MySQL statement hanlde with: mysql_stmt_close(); But this API call hangs... (below the strace output) This was working fine in older versions... Seb strace log: ... sendto(3, "s\0\0\0\26select COUNT(*) from t2 a"..., 119, 0, NULL, 0) = 119 recvfrom(3, "\f\0\0\1\0\1\0\0\0\1\0\0\0\0\0\0\36\0\0\2\3def\0\0\0\10COUN"..., 16384, 0, NULL, NULL) = 50 sendto(3, "\n\0\0\0\27\1\0\0\0\1\1\0\0\0", 14, 0, NULL, 0) = 14 recvfrom(3, 0x62905220, 16384, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) ... When mysql_stmt_close() is called, hangs in recvfrom(): recvfrom(3, On 07/03/2016 06:55 PM, Sebastien FLAESCH wrote: Hi all, I use the following technique to cancel a long running query: In the SIGINT signal handler, I restart a connection and I perform a KILL QUERY mysql-process-id-of-running-query This was working find with MySQL 5.6. But with 5.7 (5.7.11), we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Query interruption with MySQL 5.7 using KILL QUERY in signal handler does no more work
About: > B) For some reason, the program does not want to exit() - (must investigate) In fact we use prepared statements with a sequence of mysql_stmt_init, mysql_stmt_prepare, mysql_stmt_execute, mysql_stmt_fetch, ... and mysql_stmt_close. After the statement was interrupted, we try to free the MySQL statement hanlde with: mysql_stmt_close(); But this API call hangs... (below the strace output) This was working fine in older versions... Seb strace log: ... sendto(3, "s\0\0\0\26select COUNT(*) from t2 a"..., 119, 0, NULL, 0) = 119 recvfrom(3, "\f\0\0\1\0\1\0\0\0\1\0\0\0\0\0\0\36\0\0\2\3def\0\0\0\10COUN"..., 16384, 0, NULL, NULL) = 50 sendto(3, "\n\0\0\0\27\1\0\0\0\1\1\0\0\0", 14, 0, NULL, 0) = 14 recvfrom(3, 0x62905220, 16384, 0, 0, 0) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) ... When mysql_stmt_close() is called, hangs in recvfrom(): recvfrom(3, On 07/03/2016 06:55 PM, Sebastien FLAESCH wrote: Hi all, I use the following technique to cancel a long running query: In the SIGINT signal handler, I restart a connection and I perform a KILL QUERY mysql-process-id-of-running-query This was working find with MySQL 5.6. But with 5.7 (5.7.11), we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Query interruption with MySQL 5.7 using KILL QUERY in signal handler does no more work
Hi all, I use the following technique to cancel a long running query: In the SIGINT signal handler, I restart a connection and I perform a KILL QUERY mysql-process-id-of-running-query This was working find with MySQL 5.6. But with 5.7 (5.7.11), we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: signal handling in mysql cli
The process list show my (killed) thread as follows: mysql> show processlist; ++-+-+---+-+--+--+--+ | Id | User| Host| db| Command | Time | State| Info | ++-+-+---+-+--+--+--+ | 20 | root| localhost:48203 | test1 | Query |0 | starting | show processlist | | 21 | mysuser | localhost:48209 | test1 | Sleep | 182 | | NULL | ++-+-+---+-+--+--+--+ Why it is in "Sleep" state?!? Seb On 06/21/2016 06:27 PM, Sebastien FLAESCH wrote: FYI, I get the same problem with MySQL 5.7.13. Seb On 06/21/2016 04:59 PM, Sebastien FLAESCH wrote: Seems that after KILL QUERY mysql-thread-id, a call to mysql_stmt_close(stmt-handle) hangs... This did not happen in 5.6 ... Will try 5.7.13 ... Seb On 06/21/2016 04:03 PM, Sebastien FLAESCH wrote: Hi all, The technique described in this thread is working fine with MySQL 5.6 (libmysqlclient). Basically, in a SIGINT signal handler, we establish a new connection to perform a KILL QUERY pid ... But with 5.7 (5.7.11) we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb On 12/03/2014 05:25 PM, 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. Doing all this stuff in a signal handler is certainly risky... no? 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
Re: signal handling in mysql cli
FYI, I get the same problem with MySQL 5.7.13. Seb On 06/21/2016 04:59 PM, Sebastien FLAESCH wrote: Seems that after KILL QUERY mysql-thread-id, a call to mysql_stmt_close(stmt-handle) hangs... This did not happen in 5.6 ... Will try 5.7.13 ... Seb On 06/21/2016 04:03 PM, Sebastien FLAESCH wrote: Hi all, The technique described in this thread is working fine with MySQL 5.6 (libmysqlclient). Basically, in a SIGINT signal handler, we establish a new connection to perform a KILL QUERY pid ... But with 5.7 (5.7.11) we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb On 12/03/2014 05:25 PM, 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. Doing all this stuff in a signal handler is certainly risky... no? 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
Re: signal handling in mysql cli
Seems that after KILL QUERY mysql-thread-id, a call to mysql_stmt_close(stmt-handle) hangs... This did not happen in 5.6 ... Will try 5.7.13 ... Seb On 06/21/2016 04:03 PM, Sebastien FLAESCH wrote: Hi all, The technique described in this thread is working fine with MySQL 5.6 (libmysqlclient). Basically, in a SIGINT signal handler, we establish a new connection to perform a KILL QUERY pid ... But with 5.7 (5.7.11) we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb On 12/03/2014 05:25 PM, 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. Doing all this stuff in a signal handler is certainly risky... no? 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
Re: signal handling in mysql cli
Hi all, The technique described in this thread is working fine with MySQL 5.6 (libmysqlclient). Basically, in a SIGINT signal handler, we establish a new connection to perform a KILL QUERY pid ... But with 5.7 (5.7.11) we get now a different result: A) The query is still interrupted, but we no longer get an SQL error -1317. B) For some reason, the program does not want to exit() - (must investigate) Any clues? With mysql it's working fine: mysql> select sleep(10); ^C^C -- query aborted +---+ | sleep(10) | +---+ +---+ 1 row in set (2.79 sec) mysql> \q Bye Thanks! Seb On 12/03/2014 05:25 PM, 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. Doing all this stuff in a signal handler is certainly risky... no? 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
C++ comment in binary_log_types.h header
Hi all, In version 5.7.10, I found a C++ comment in the .h headers: #endif // __cplusplus Should be: #endif /* __cplusplus */ To avoid: cc -g -fsanitize=address -fno-omit-frame-pointer -W -Wall -pedantic -Wmissing-prototypes \ -Wno-long-long -Werror -fPIC \ -I/opt3/dbs/mys/5.7/include \ mys.c -o mys_5_7.o In file included from /opt3/dbs/mys/5.7/include/mysql_com.h:22:0, from /opt3/dbs/mys/5.7/include/mysql.h:58, from mys.c:41: /opt3/dbs/mys/5.7/include/binary_log_types.h:68:8: error: C++ style comments are not allowed in ISO C90 [-Werror] #endif // __cplusplus */ Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: signal handling in mysql cli
Thank you Rafal for your answer!
We do not use threads, it's a single threaded program. So we cannot set
a flag to exec the KILL QUERY later on in another thread.
The only flag I use is to avoid subsequent KILL QUERY attempts when one
has already been sent...
The code in the sigint handler is quite simple, basic mysql_ calls and
debug messages (fprintfs):
if (currConn currConn-canInterrupt) {
char cmd[50];
MYSQL *h;
currConn-canInterrupt = 0;
h = mysql_init(NULL);
if (!mysql_real_connect(h, currConn-c_host, currConn-c_user,
currConn-c_auth, currConn-c_dbnm,
currConn-c_port, currConn-c_sock,
CLIENT_FOUND_ROWS)) {
DBGMSGINT(2, Interrupt: Could not connect to database: %d.,
mysql_errno(h));
return 0;
}
sprintf(cmd, KILL QUERY %ld, currConn-threadId);
if (mysql_query(h, cmd) != 0) {
DBGMSGSTR(2, Could not execute %s., cmd);
}
mysql_close(h);
}
Should do the job...
Thanks.
Seb
On 12/12/2014 12:12 PM, rafal somla wrote:
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
Re: signal handling in mysql cli
Nobody concerned by this case? Simple question: is it safe or not to do a KILL QUERY in a SIGINT signal handler? S. On 12/03/2014 05:25 PM, 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. Doing all this stuff in a signal handler is certainly risky... no? 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
Re: signal handling in mysql cli
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. Doing all this stuff in a signal handler is certainly risky... no? 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
Re: MySQL Community Server 5.6.13 has been released
Hello, 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? Thanks, Seb On 07/31/2013 01:03 PM, Sunanda Menon wrote: Dear MySQL users, MySQL Server 5.6.13, a new version of the popular Open Source Database Management System, has been released. MySQL 5.6.13 is recommended for use on production systems. For an overview of what's new in MySQL 5.6, please see http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6 are available both as a full installer and as a web installer. The full installer is significantly larger and comes bundled with the latest software releases available. This bundle makes it easy to download and configure a full server and development suite. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. For information on installing MySQL 5.6.13 on new servers or upgrading to MySQL 5.6.13 from previous MySQL releases, please see http://dev.mysql.com/doc/refman/5.6/en/installing.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ Not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc: https://wikis.oracle.com/display/mysql/Contributing The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.6. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html Enjoy! Changes in MySQL 5.6.13 (2013-07-31) A known limitation of this release: Note On Microsoft Windows, MySQL Installer will not upgrade MySQL Enterprise Backup (MEB) 3.8.1 to 3.8.2 (latest version). A workaround is to uninstall MEB 3.8.1 and then install MEB 3.8.2 (latest version) with MySQL Installer. Functionality Added or Changed * Important Change; Replication: By default, when promoting integers from a smaller type on the master to a larger type on the slave (for example, from a SMALLINT column on the master to a BIGINT column on the slave), the promoted values are treated as though they are signed. Now in such cases it is possible to modify or override this behavior using one or both of ALL_SIGNED, ALL_UNSIGNED in the set of values specified for the slave_type_conversions server system variable. For more information, see Row-based replication: attribute promotion and demotion (http://dev.mysql.com/doc/refman/5.6/en/replication-features-differing-tables.html) #replication-features-attribute-promotion) , as well as the description of the variable. (Bug #15831300) * Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. For example: Warning: Using unique option prefix compr instead of compress is deprecated and will be removed in a future release. Please use the full name instead. Option prefixes are no longer supported in MySQL 5.7; only full options are accepted. (Bug #16996656) * 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) * In batch mode, mysql formatted result status messages such as Query OK, 1 row affected but did not print them. Now these messages are not formatted. (Bug #69486, Bug #16971432) Bugs Fixed * Performance; Important Change; InnoDB: InnoDB would fail to open a tablespace that has multiple data files. This removes the known
Re: MySQL Client (libmysqlclient) compatibility policy
Hi all, Could someone from the libmysqlclient contributors comment on this, and could someone complete the documentation regarding client compatiblity? Thanks! Seb On 02/20/2013 09:31 AM, Sebastien FLAESCH wrote: Hello, FYI, I found this statement in the doc, at the end of the C API main page: http://dev.mysql.com/doc/refman/5.6/en/c.html If, after an upgrade, you experience problems with compiled client programs, such as Commands out of sync or unexpected core dumps, you probably have used old header or library files when compiling your programs. In this case, check the date for your mysql.h file and libmysqlclient.a library to verify that they are from the new MySQL distribution. If not, recompile your programs with the new headers and libraries. Recompilation might also be necessary for programs compiled against the shared client library if the library major version number has changed (for example from libmysqlclient.so.15 to libmysqlclient.so.16. ... This sounds like guessing/hoping that the a client program compiled/linked with older headers/libmysqlclient can eventually work with a more recent client lib. There should be a clear rule for that. A simple rule could be that it's mandatory to recompile when upgrading to a new production release (5.5 to 5.6), even if the client libs are still compatible. Further, I would expect to see such note in Building Client Programs: http://dev.mysql.com/doc/refman/5.6/en/building-clients.html Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL Client (libmysqlclient) compatibility policy
Beside the Oracle skills debate and the stupid mistakes with soname changes between 5.5.8 and 5.5.10 or 5.6.x, (imagine all of this did not happen): I have a VERY simple question that needs a VERY CLEAR answer: In our distribution packages (for different platforms! not only Linux), I need to provide mysql client binaries for different versions of mysql client environments: 4.1.x 5.1.x 5.4.x 5.5.x 5.6.x How many binaries do I have to provide to support all these versions? We compile with headers of a given version and link dynamically with -lmysqlclient of course. Thanks... Seb On 05/17/2013 11:26 AM, Reindl Harald wrote: Oracle fails the context by make incompatible ABI changes which are *expected* by raise the minor release number but claim they are compatible until it is clear that random things are broken and the soname needs to be changed what leaves the question: was the QA at holiday due the whole development cycle? * MySQL 5.5.8 was the GA release * MySQL 5.5.10 changed the soname * *wow* the same happens now again with 5.6? * this leaded in mass-rebuilds for linux-distributions after GA * maybe one of the reasons why Oracle MySQL get dropped everywhere and replaced by MariaDB and instead to accept the fact as example in Fedora Oracle stepped in and make things more complicated by try to figure out how both forks can be in the distribution instead doing a clean cut everybody but Oracle knows when you need to raise the so-number to make sure any package-managment prevents the enduser to end in incompatible linked applications, if the so-number would be raised RPM would *not allow* to install the new client library until all depending packages are rebuilt and if something like the 5.5.10 breakage happens more than once i claim someone to be learning resistent Changes in MySQL 5.5.10 (2011-03-15) Incompatible Change: The shared library version of the client library was increased to 18 to reflect ABI changes, and avoid compatibility problems with the client library in MySQL 5.1. Note that this is an incompatible change between 5.5.10 and earlier 5.5 versions, so client programs that use the 5.5 client library should be recompiled against the 5.5.10 client library. (Bug #60061, Bug #11827366) Am 17.05.2013 11:10, schrieb Sebastien FLAESCH: Could someone from the libmysqlclient contributors comment on this, and could someone complete the documentation regarding client compatiblity? On 02/20/2013 09:31 AM, Sebastien FLAESCH wrote: Hello, FYI, I found this statement in the doc, at the end of the C API main page: http://dev.mysql.com/doc/refman/5.6/en/c.html If, after an upgrade, you experience problems with compiled client programs, such as Commands out of sync or unexpected core dumps, you probably have used old header or library files when compiling your programs. In this case, check the date for your mysql.h file and libmysqlclient.a library to verify that they are from the new MySQL distribution. If not, recompile your programs with the new headers and libraries. Recompilation might also be necessary for programs compiled against the shared client library if the library major version number has changed (for example from libmysqlclient.so.15 to libmysqlclient.so.16. ... This sounds like guessing/hoping that the a client program compiled/linked with older headers/libmysqlclient can eventually work with a more recent client lib. There should be a clear rule for that. A simple rule could be that it's mandatory to recompile when upgrading to a new production release (5.5 to 5.6), even if the client libs are still compatible. Further, I would expect to see such note in Building Client Programs: http://dev.mysql.com/doc/refman/5.6/en/building-clients.html Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL Client (libmysqlclient) compatibility policy
On 05/17/2013 12:29 PM, Reindl Harald wrote: Am 17.05.2013 12:05, schrieb Sebastien FLAESCH: Beside the Oracle skills debate and the stupid mistakes with soname changes between 5.5.8 and 5.5.10 or 5.6.x, (imagine all of this did not happen): I have a VERY simple question that needs a VERY CLEAR answer: In our distribution packages (for different platforms! not only Linux), I need to provide mysql client binaries for different versions of mysql client environments: 4.1.x 5.1.x 5.4.x 5.5.x 5.6.x How many binaries do I have to provide to support all these versions? We compile with headers of a given version and link dynamically with -lmysqlclient of course 4.1 and 5.6 should be enough if the topic is only to connect to servers from 4.1 to 5.6, a 5.6 client will happily connct to a= 5.1 server 4.1 has a older protocol version and is AFAIk not supported by recent client libraries, at least recent PHP versions can not connect to servers older than 5.x I see want you mean regarding C/S protocols but understand that: 1- we do not ship the MySQL client library, 2- it's not sure that a 5.6 (or 4.1) libmysqlclient is installed. Typically, customers will install a MySQL 5.x.y server WITH the corresponding 5.x.y MySQL client library (usually on the same machine), then they install our software (it's a dev tool). So you can have following scenario: A- MySQL Version 5.4.x with: libmysqlclient.so.16 B- Our product, with a db interface module for MySQL. If we use MySQL 5.6.x to build it, it will be linked to: libmysqlclient.so.18 I suppose linking our modules to libmysqlclient.so without a lib version name is not good practice... ;-) Until today, if we want to have a common and simple rule for all plaforms, my instinct is that we better provide a binary compiled and linked with each major version of the MySQL we want to support. This implies MySQL version specific modules in our package, but guaranties 100% compatibility with the different MySQL client libs that can be in the field. Am I wrong? Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL Client (libmysqlclient) compatibility policy
On 05/17/2013 03:07 PM, Reindl Harald wrote: Am 17.05.2013 14:53, schrieb Sebastien FLAESCH: On 05/17/2013 12:29 PM, Reindl Harald wrote: Am 17.05.2013 12:05, schrieb Sebastien FLAESCH: Beside the Oracle skills debate and the stupid mistakes with soname changes between 5.5.8 and 5.5.10 or 5.6.x, (imagine all of this did not happen): I have a VERY simple question that needs a VERY CLEAR answer: In our distribution packages (for different platforms! not only Linux), I need to provide mysql client binaries for different versions of mysql client environments: 4.1.x 5.1.x 5.4.x 5.5.x 5.6.x How many binaries do I have to provide to support all these versions? We compile with headers of a given version and link dynamically with -lmysqlclient of course 4.1 and 5.6 should be enough if the topic is only to connect to servers from 4.1 to 5.6, a 5.6 client will happily connct to a= 5.1 server 4.1 has a older protocol version and is AFAIk not supported by recent client libraries, at least recent PHP versions can not connect to servers older than 5.x I see want you mean regarding C/S protocols but understand that: 1- we do not ship the MySQL client library so you must require it as dependency 2- it's not sure that a 5.6 (or 4.1) libmysqlclient is installed. you have to make sure it Typically, customers will install a MySQL 5.x.y server WITH the corresponding 5.x.y MySQL client library (usually on the same machine), then they install our software (it's a dev tool). and you only need to specify this as requirement Until today, if we want to have a common and simple rule for all plaforms, my instinct is that we better provide a binary compiled and linked with each major version of the MySQL we want to support. no - typically you require the mysql libraries to be installed in a specific version, or ship them with your package if possible by license, but the latter is a bad practice because nobody will update the libs in case of security fixes and this perverts the concept of shared libraries For sure we'll not provide the MySQL libs in our packages! But as I wrote, we support other platforms as Linux, and AIX/HP/Solaris or Windows users will not have rpm ou deb packages with automatic soname lib version checking... We have our own installation program for all Unix platforms and we need a common rule, for different versions on these operating systems... We cannot force customers to install a MySQL 5.6 client lib, when they have a 5.1, 5.4 or 5.5 server, especially when installed on an old Linux where you cannot get a more recent version of the client lib... Further, even if migrating to the last MySQL version is possible regarding the OS version, some customers can stay with a given db version for years and we have to support this. Anyway, basically I think you answered to my main compatibility question... Didn't you? ;-) Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL Client (libmysqlclient) compatibility policy
Hello, FYI, I found this statement in the doc, at the end of the C API main page: http://dev.mysql.com/doc/refman/5.6/en/c.html If, after an upgrade, you experience problems with compiled client programs, such as Commands out of sync or unexpected core dumps, you probably have used old header or library files when compiling your programs. In this case, check the date for your mysql.h file and libmysqlclient.a library to verify that they are from the new MySQL distribution. If not, recompile your programs with the new headers and libraries. Recompilation might also be necessary for programs compiled against the shared client library if the library major version number has changed (for example from libmysqlclient.so.15 to libmysqlclient.so.16. ... This sounds like guessing/hoping that the a client program compiled/linked with older headers/libmysqlclient can eventually work with a more recent client lib. There should be a clear rule for that. A simple rule could be that it's mandatory to recompile when upgrading to a new production release (5.5 to 5.6), even if the client libs are still compatible. Further, I would expect to see such note in Building Client Programs: http://dev.mysql.com/doc/refman/5.6/en/building-clients.html Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
MySQL Client (libmysqlclient) compatibility policy
Hi all, What is the compatibility policy regarding the MySQL C API library? I could not find the rules in the documentation. I have several versions of MySQL installed on my Linux, and it appears that the libmysqlclient versions have changed in the 5.x version line: /opt3/dbs/mys/4.1.24/lib/libmysqlclient.so.14 /opt3/dbs/mys/5.0.90/lib/libmysqlclient.so.15 /opt3/dbs/mys/5.1.35/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.1.51/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.4.0/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.5.1/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.5.19/lib/libmysqlclient.so.18 /opt3/dbs/mys/5.6.10/lib/libmysqlclient.so.18 What's the rule? Is a 5.6 compatible to 5.5 because they have the same library version number (.18) ? What about other platforms not using library version numbers? Is there any lib client version compatibility checking when initializing the client library? That would prevent from invalid combinations of there is a compatibility issue. Can a C program compiled/linked with the 5.6.* client be used with all the older and future 5.* clients? Or is 5.6 a major version compared to 5.5, that requires a recompilation and re-link of the C client programs? This is critical for software vendors that want to provide a database client/driver for different versions of MySQL, using the native MySQL C client API (without going through ODBC or other layers). Thanks! Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: MySQL Client (libmysqlclient) compatibility policy
On 02/18/2013 12:14 PM, Noel Butler wrote: On Mon, 2013-02-18 at 10:57 +0100, Sebastien FLAESCH wrote: I have several versions of MySQL installed on my Linux, and it appears that the libmysqlclient versions have changed in the 5.x version line: /opt3/dbs/mys/4.1.24/lib/libmysqlclient.so.14 /opt3/dbs/mys/5.0.90/lib/libmysqlclient.so.15 /opt3/dbs/mys/5.1.35/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.1.51/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.4.0/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.5.1/lib/libmysqlclient.so.16 /opt3/dbs/mys/5.5.19/lib/libmysqlclient.so.18 /opt3/dbs/mys/5.6.10/lib/libmysqlclient.so.18 Asking for trouble, rebuild what depends on latest, and get rid of all that ancient crud. Its not like it changes with every release, so its only a very minor inconvenience, and if you have separate servers for each functions like SP's do, then it's an even smaller inconvenience per server. Sorry, I should have mentioned that we are a development tool vendor. We sell a compiler and runtime system that allows to write applications in a 4gl language, for different sort of databases, and we deliver what we call database drivers for each of the supported dbs types. We support Oracle, SQL Server, DB2 UDB, PostgreSQL, MySQL, Sybase ASE, SQLite and Informix IDS ... For each of these dbs types, we have to support the latest versions of the client libraries. This has a cost in terms of porting and QA tests. Regarding MySQL, we support today the following versions, and we have a db driver for each of them: 4.1.x 5.0.x 5.1.x 5.4.x 5.5.x 5.6.x (soon) We want to reduce as much as possible the number of drivers we deliver. Beside new SQL features that could be introduced between 5.x versions, we need to know the compatibility policy regarding the MySQL client lib. Another option could be to support only 5.6, and ask customers to install the corresponding client lib, by keeping the server in a 5.x version. Thanks Seb -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
