Re: signal handling in mysql cli

2016-06-30 Thread shawn l.green

Hello Sebastien,

You should stop top-posting, it inverts the flow of your investigation 
making it harder to follow. (see bottom)


On 6/21/2016 12:45 PM, Sebastien FLAESCH wrote:

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

















You did not KILL the entire client session(CONNECTION), you only killed 
the QUERY that the session was executing. The client remains connected 
and the session remains active. The reason it is in Sleep state is 
because the server is waiting for the client to send its next command.


http://dev.mysql.com/doc/refman/5.7/en/kill.html

--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


--
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

2016-06-21 Thread Sebastien FLAESCH

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

2016-06-21 Thread Sebastien FLAESCH

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

2016-06-21 Thread Sebastien FLAESCH

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

2016-06-21 Thread Sebastien FLAESCH

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: Re: signal handling in mysql cli

2014-12-12 Thread rafal somla

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

2014-12-12 Thread Sebastien FLAESCH

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

2014-12-10 Thread Sebastien FLAESCH

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

2014-12-10 Thread Johan De Meersman
- Original Message -
 From: Sebastien FLAESCH s...@4js.com
 Subject: 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?

I don't see what the extra risk would be as opposed to doing so in any other 
thread of your code, or in another program entirely. As long as you're sure 
about which particular query you're shooting in the face, it should be 
perfectly fine.


-- 
Unhappiness is discouraged and will be corrected with kitten pictures.

-- 
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

2014-12-03 Thread walter harms


Am 02.12.2014 18:31, schrieb Johan De Meersman:
 - Original Message -
 From: wharms wha...@bfs.de
 Subject: signal handling in mysql cli

 when i use CTRL-C to break a query that works fine in interactive mode.

 but when i use the noninteractive mode
 i looks like that  but show full processlist; shows otherwise and that is 
 true
 
 This may sound silly, but you're basically saying that you can't interact 
 with it while in non-interactive mode...
 
 My understanding may be wrong, but this is how it works in my mind:
  * when in the client, the client intercepts the ctrl-c and interprets it as 
 kill this query on the server.
  * when in non-interactive mode, the client is not actually reading your 
 keypresses. Thus, the ctrl-c gets intercepted by the *shell*, which does 
 exactly what you ask by killing the MySQL client process.
 
 Now, if the mysql client does not explicitly intercept kill signals - which, 
 honestly, most programs have no reason to - that means it doesn't even get a 
 chance to send the cancel that query order, it just dies.
 
 A lot of debate could be put in on wether or not the client needs to 
 intercept and send a cancel, but personally I'm leaning towards no, it 
 doesn't - if you don't have a transaction open, or don't even have a 
 transactional engine (which used to be default!) cancelling would leave your 
 database in an inconsistent state. Much better, then, to allow whatever query 
 you sent to continue, on the off chance that it's something that it does not 
 damage, or only does things that you can reverse afterwards. If you really 
 want to kill that query, you always have the option of logging into the 
 server and shooting it yourself.
 

In Unix pressing CTRL-C should be the same a sending a INTR.
You can see this with stty -a what key is map to what signal.

NTL the question is: how can the user stop the query what was started with a 
script ?

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

2014-12-03 Thread Sebastien FLAESCH

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



signal handling in mysql cli

2014-12-02 Thread walter harms
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

2014-12-02 Thread Johan De Meersman
- Original Message -
 From: wharms wha...@bfs.de
 Subject: signal handling in mysql cli
 
 when i use CTRL-C to break a query that works fine in interactive mode.
 
 but when i use the noninteractive mode
 i looks like that  but show full processlist; shows otherwise and that is 
 true

This may sound silly, but you're basically saying that you can't interact with 
it while in non-interactive mode...

My understanding may be wrong, but this is how it works in my mind:
 * when in the client, the client intercepts the ctrl-c and interprets it as 
kill this query on the server.
 * when in non-interactive mode, the client is not actually reading your 
keypresses. Thus, the ctrl-c gets intercepted by the *shell*, which does 
exactly what you ask by killing the MySQL client process.

Now, if the mysql client does not explicitly intercept kill signals - which, 
honestly, most programs have no reason to - that means it doesn't even get a 
chance to send the cancel that query order, it just dies.

A lot of debate could be put in on wether or not the client needs to intercept 
and send a cancel, but personally I'm leaning towards no, it doesn't - if you 
don't have a transaction open, or don't even have a transactional engine (which 
used to be default!) cancelling would leave your database in an inconsistent 
state. Much better, then, to allow whatever query you sent to continue, on the 
off chance that it's something that it does not damage, or only does things 
that you can reverse afterwards. If you really want to kill that query, you 
always have the option of logging into the server and shooting it yourself.

/johan


-- 
Unhappiness is discouraged and will be corrected with kitten pictures.

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql