Fix bug 1580227 (Killed connection threads might get their sockets cl… #500
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…osed twice on shutdown) In some scenarios, THD::disconnect might get called twice for a single connection, e.g. the first time by kill_server_threads -> kill_server -> close_connections -> close_connection, and the second time by handle_one_connection -> do_handle_one_connection -> close_connection. This will result in the 1st call closing the network socket and setting it to -1 and the 2nd call calling close on -1. Fix by checking VIO state before calling close on the socket.
|
LGTM |
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 23, 2020
Summary: Interface MySQL provides for implementing custom storage engines is quite cumbersome. For the purposes of the debugging and understanding the flow of execution we need to be able to clearly observe and trace how MyRocks code is being called. Interface itself is described in `sql\handler.h`. As a standard solution, MySQL exposes DBUG package and various macros associated with it. This set of changes makes sure that every call to any of the functions MyRocks implements will be tracked with a pair of `DBUG_FUNC_CALL` and `DBUG_RETURN*` macros. We can now change DBUG settings during runtime (`SET GLOBAL debug = '+d,enter,exit:L';` or something similar) and observe the execution flow. `DBUG_FUNC_CALL` is a simple customization based on `DBUG_ENTER` and it uses `__PRETTY_FUNCTION__` to delegate the work of composing correct function names to a compiler. Yes, this functionality is specific to `Clang` or `GCC` and these are the only toolsets we care about now. For future references: please use Closes facebook/mysql-5.6#500 Reviewed By: lth Differential Revision: D4391700 Pulled By: gunnarku fbshipit-source-id: 56f2c001f56
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Feb 24, 2021
Summary: Interface MySQL provides for implementing custom storage engines is quite cumbersome. For the purposes of the debugging and understanding the flow of execution we need to be able to clearly observe and trace how MyRocks code is being called. Interface itself is described in `sql\handler.h`. As a standard solution, MySQL exposes DBUG package and various macros associated with it. This set of changes makes sure that every call to any of the functions MyRocks implements will be tracked with a pair of `DBUG_FUNC_CALL` and `DBUG_RETURN*` macros. We can now change DBUG settings during runtime (`SET GLOBAL debug = '+d,enter,exit:L';` or something similar) and observe the execution flow. `DBUG_FUNC_CALL` is a simple customization based on `DBUG_ENTER` and it uses `__PRETTY_FUNCTION__` to delegate the work of composing correct function names to a compiler. Yes, this functionality is specific to `Clang` or `GCC` and these are the only toolsets we care about now. For future references: please use Closes facebook/mysql-5.6#500 Reviewed By: lth Differential Revision: D4391700 Pulled By: gunnarku fbshipit-source-id: 56f2c001f56
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Nov 15, 2021
…ercona#500) Summary: Interface MySQL provides for implementing custom storage engines is quite cumbersome. For the purposes of the debugging and understanding the flow of execution we need to be able to clearly observe and trace how MyRocks code is being called. Interface itself is described in `sql\handler.h`. As a standard solution, MySQL exposes DBUG package and various macros associated with it. This set of changes makes sure that every call to any of the functions MyRocks implements will be tracked with a pair of `DBUG_FUNC_CALL` and `DBUG_RETURN*` macros. We can now change DBUG settings during runtime (`SET GLOBAL debug = '+d,enter,exit:L';` or something similar) and observe the execution flow. `DBUG_FUNC_CALL` is a simple customization based on `DBUG_ENTER` and it uses `__PRETTY_FUNCTION__` to delegate the work of composing correct function names to a compiler. Yes, this functionality is specific to `Clang` or `GCC` and these are the only toolsets we care about now. For future references: please use Closes facebook/mysql-5.6#500 Reviewed By: lloyd Differential Revision: D4391700 (facebook/mysql-5.6@d72c1b0) Pulled By: gunnarku fbshipit-source-id: 5be721c0bc8
ldonoso
pushed a commit
to ldonoso/percona-server
that referenced
this pull request
Mar 15, 2022
…ercona#500) Summary: Interface MySQL provides for implementing custom storage engines is quite cumbersome. For the purposes of the debugging and understanding the flow of execution we need to be able to clearly observe and trace how MyRocks code is being called. Interface itself is described in `sql\handler.h`. As a standard solution, MySQL exposes DBUG package and various macros associated with it. This set of changes makes sure that every call to any of the functions MyRocks implements will be tracked with a pair of `DBUG_FUNC_CALL` and `DBUG_RETURN*` macros. We can now change DBUG settings during runtime (`SET GLOBAL debug = '+d,enter,exit:L';` or something similar) and observe the execution flow. `DBUG_FUNC_CALL` is a simple customization based on `DBUG_ENTER` and it uses `__PRETTY_FUNCTION__` to delegate the work of composing correct function names to a compiler. Yes, this functionality is specific to `Clang` or `GCC` and these are the only toolsets we care about now. For future references: please use Closes facebook/mysql-5.6#500 Reviewed By: lloyd Differential Revision: D4391700 Pulled By: gunnarku
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 9, 2024
…ercona#500) Summary: Interface MySQL provides for implementing custom storage engines is quite cumbersome. For the purposes of the debugging and understanding the flow of execution we need to be able to clearly observe and trace how MyRocks code is being called. Interface itself is described in `sql\handler.h`. As a standard solution, MySQL exposes DBUG package and various macros associated with it. This set of changes makes sure that every call to any of the functions MyRocks implements will be tracked with a pair of `DBUG_FUNC_CALL` and `DBUG_RETURN*` macros. We can now change DBUG settings during runtime (`SET GLOBAL debug = '+d,enter,exit:L';` or something similar) and observe the execution flow. `DBUG_FUNC_CALL` is a simple customization based on `DBUG_ENTER` and it uses `__PRETTY_FUNCTION__` to delegate the work of composing correct function names to a compiler. Yes, this functionality is specific to `Clang` or `GCC` and these are the only toolsets we care about now. For future references: please use Closes facebook/mysql-5.6#500 Reviewed By: lloyd Differential Revision: D4391700 Pulled By: gunnarku
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…osed twice on shutdown)
In some scenarios, THD::disconnect might get called twice for a single
connection, e.g. the first time by kill_server_threads -> kill_server
-> close_connections -> close_connection, and the second time by
handle_one_connection -> do_handle_one_connection ->
close_connection. This will result in the 1st call closing the network
socket and setting it to -1 and the 2nd call calling close on -1.
Fix by checking VIO state before calling close on the socket.
http://jenkins.percona.com/job/percona-server-5.6-param/1129