From 8b00a00ea788c29b0cd37b2c1201d5bfc006df2f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Sat, 8 Dec 2018 00:53:39 +0200 Subject: [PATCH 1/6] MXS-2216: Use correct function in response processing When a response to a prepared statement was processed, the number of EOF packets was used to see whether the response was complete. This code used a function that does not work with the special packet returned by a PS preparation that is similar to an OK packet. The correct method is to count the total number of packets in the response. --- .../protocol/MySQL/mariadbbackend/mysql_backend.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c b/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c index 448d1da71..2e3dfdf93 100644 --- a/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c +++ b/server/modules/protocol/MySQL/mariadbbackend/mysql_backend.c @@ -659,24 +659,25 @@ static inline bool complete_ps_response(GWBUF *buffer) if (mxs_mysql_extract_ps_response(buffer, &resp)) { - int expected_eof = 0; + int expected_packets = 1; if (resp.columns > 0) { - expected_eof++; + // Column definition packets plus one for the EOF + expected_packets += resp.columns + 1; } if (resp.parameters > 0) { - expected_eof++; + // Parameter definition packets plus one for the EOF + expected_packets += resp.parameters + 1; } - bool more; - int n_eof = modutil_count_signal_packets(buffer, 0, &more, NULL); + int n_packets = modutil_count_packets(buffer); - MXS_DEBUG("Expecting %u EOF, have %u", n_eof, expected_eof); + MXS_DEBUG("Expecting %u packets, have %u", n_packets, expected_packets); - rval = n_eof == expected_eof; + rval = n_packets == expected_packets; } return rval; From 48efa6d0271ac7337f6b7174229bb5176e9d05ea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Sat, 8 Dec 2018 00:58:46 +0200 Subject: [PATCH 2/6] MXS-2213: Clear stored PS information The information stored for each prepared statement would not be cleared until the end of the session. This is a problem if the sessions last for a very long time as the stored information is unused once a COM_STMT_CLOSE has been received. In addition to this, the session command response maps were not cleared correctly if all backends had processed all session commands. --- .../routing/readwritesplit/rwsplit_route_stmt.cc | 14 ++++++++++++++ .../routing/readwritesplit/rwsplitsession.cc | 4 ++++ 2 files changed, 18 insertions(+) diff --git a/server/modules/routing/readwritesplit/rwsplit_route_stmt.cc b/server/modules/routing/readwritesplit/rwsplit_route_stmt.cc index d9d1f5105..0ac458292 100644 --- a/server/modules/routing/readwritesplit/rwsplit_route_stmt.cc +++ b/server/modules/routing/readwritesplit/rwsplit_route_stmt.cc @@ -202,6 +202,15 @@ bool route_single_stmt(RWSplit *inst, RWSplitSession *rses, GWBUF *querybuf, con if (not_locked_to_master && is_ps_command(command)) { + if (command == MXS_COM_STMT_CLOSE) + { + // Remove the command from the PS mapping + ss_dassert(TARGET_IS_ALL(route_target)); + rses->ps_manager.erase(stmt_id); + rses->ps_handles.erase(mxs_mysql_extract_ps_id(querybuf)); + rses->exec_map.erase(stmt_id); + } + /** Replace the client statement ID with our internal one only if the * target node is not the current master */ replace_binary_ps_id(querybuf, stmt_id); @@ -422,6 +431,11 @@ bool route_session_write(RWSplitSession *rses, GWBUF *querybuf, { rses->sescmd_responses.erase(rses->sescmd_responses.begin(), it); } + else + { + // All responses processed + rses->sescmd_responses.clear(); + } } else { diff --git a/server/modules/routing/readwritesplit/rwsplitsession.cc b/server/modules/routing/readwritesplit/rwsplitsession.cc index beeba1bbc..858614f3b 100644 --- a/server/modules/routing/readwritesplit/rwsplitsession.cc +++ b/server/modules/routing/readwritesplit/rwsplitsession.cc @@ -86,6 +86,10 @@ bool RWBackend::write(GWBUF* buffer, response_type type) // Any non-zero flag value means that we have an open cursor m_opening_cursor = flags != 0; } + else if (cmd == MXS_COM_STMT_CLOSE) + { + m_ps_handles.erase(it); + } else if (cmd == MXS_COM_STMT_FETCH) { // Number of rows to fetch is a 4 byte integer after the ID From f2a3a5737a1618b0fe820c0de4b3a531e874aee9 Mon Sep 17 00:00:00 2001 From: Niclas Antti Date: Tue, 11 Dec 2018 13:51:44 +0200 Subject: [PATCH 3/6] MXS-2221 Fatal signal handling does not always create a core Quick and simple fix, but this should be overhauled. See MXS-599. --- server/core/gateway.cc | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/server/core/gateway.cc b/server/core/gateway.cc index 3482315fb..91da2c46d 100644 --- a/server/core/gateway.cc +++ b/server/core/gateway.cc @@ -493,12 +493,12 @@ void extract_file_and_line(const char* symbols, char* cmd, size_t size) static void sigfatal_handler(int i) { - if (fatal_handling) - { - fprintf(stderr, "Fatal signal %d while backtracing\n", i); - _exit(1); - } - fatal_handling = 1; + // The same signal being handled *now* can occur in another thread (and is often likely). + // By setting the default handler here we will always get a core, but not necessarily + // the backtrace into the log file. This should be overhauled to proper signal handling + // (MXS-599). + signal_set(i, SIG_DFL); + MXS_CONFIG* cnf = config_get_global_options(); fprintf(stderr, "Fatal: MaxScale " MAXSCALE_VERSION " received fatal signal %d. " "Attempting backtrace.\n", i); @@ -539,7 +539,6 @@ sigfatal_handler(int i) /* re-raise signal to enforce core dump */ fprintf(stderr, "\n\nWriting core dump\n"); - signal_set(i, SIG_DFL); raise(i); } From 136c0c3062eb0bb51be4f427ec24303b62b71a9e Mon Sep 17 00:00:00 2001 From: Johan Wikman Date: Wed, 12 Dec 2018 12:42:51 +0200 Subject: [PATCH 4/6] Add release notes for 2.2.18 and update change log --- Documentation/Changelog.md | 1 + .../MaxScale-2.2.18-Release-Notes.md | 37 +++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100644 Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md diff --git a/Documentation/Changelog.md b/Documentation/Changelog.md index c260f0379..baea690a5 100644 --- a/Documentation/Changelog.md +++ b/Documentation/Changelog.md @@ -28,6 +28,7 @@ the master. There is also limited capability for rejoining nodes. For more details, please refer to: +* [MariaDB MaxScale 2.2.18 Release Notes](Release-Notes/MaxScale-2.2.18-Release-Notes.md) * [MariaDB MaxScale 2.2.17 Release Notes](Release-Notes/MaxScale-2.2.17-Release-Notes.md) * [MariaDB MaxScale 2.2.16 Release Notes](Release-Notes/MaxScale-2.2.16-Release-Notes.md) * [MariaDB MaxScale 2.2.15 Release Notes](Release-Notes/MaxScale-2.2.15-Release-Notes.md) diff --git a/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md b/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md new file mode 100644 index 000000000..2f76aa77a --- /dev/null +++ b/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md @@ -0,0 +1,37 @@ +# MariaDB MaxScale 2.2.18 Release Notes + +Release 2.2.18 is a GA release. + +This document describes the changes in release 2.2.18, when compared to the +previous release in the same series. + +For any problems you encounter, please consider submitting a bug +report on [our Jira](https://jira.mariadb.org/projects/MXS). + +## Bug fixes + +* [MXS-2221](https://jira.mariadb.org/browse/MXS-2221) Fatal signal handling does not always create a core +* [MXS-2216](https://jira.mariadb.org/browse/MXS-2216) Read past stack buffer +* [MXS-2213](https://jira.mariadb.org/browse/MXS-2213) Growing memory consumption with 2.2.17 +* [MXS-2207](https://jira.mariadb.org/browse/MXS-2207) qc_mysqlembedded does not classify SET STATEMENT ... FOR UPDATE correctly. +* [MXS-2183](https://jira.mariadb.org/browse/MXS-2183) Excessive memory use, but not growing endlessly + +## Known Issues and Limitations + +There are some limitations and known issues within this version of MaxScale. +For more information, please refer to the [Limitations](../About/Limitations.md) document. + +## Packaging + +RPM and Debian packages are provided for supported the Linux distributions. + +Packages can be downloaded [here](https://mariadb.com/downloads/mariadb-tx/maxscale). + +## Source Code + +The source code of MaxScale is tagged at GitHub with a tag, which is identical +with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale +is `maxscale-X.Y.Z`. Further, the default branch is always the latest GA version +of MaxScale. + +The source code is available [here](https://github.com/mariadb-corporation/MaxScale). From bad8c03df96d550fe5d71aacea66b573b009a892 Mon Sep 17 00:00:00 2001 From: Johan Wikman Date: Wed, 12 Dec 2018 13:04:07 +0200 Subject: [PATCH 5/6] Update version number --- VERSION22.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION22.cmake b/VERSION22.cmake index f9a456930..6ba5b4cc3 100644 --- a/VERSION22.cmake +++ b/VERSION22.cmake @@ -5,7 +5,7 @@ set(MAXSCALE_VERSION_MAJOR "2" CACHE STRING "Major version") set(MAXSCALE_VERSION_MINOR "2" CACHE STRING "Minor version") -set(MAXSCALE_VERSION_PATCH "18" CACHE STRING "Patch version") +set(MAXSCALE_VERSION_PATCH "19" CACHE STRING "Patch version") # This should only be incremented if a package is rebuilt set(MAXSCALE_BUILD_NUMBER 1 CACHE STRING "Release number") From 562bd0c3fb4d40cac4ec4d84c0c277e34f78b345 Mon Sep 17 00:00:00 2001 From: Johan Wikman Date: Thu, 13 Dec 2018 10:55:08 +0200 Subject: [PATCH 6/6] Update release date --- Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md b/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md index 2f76aa77a..d20cfab6f 100644 --- a/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md +++ b/Documentation/Release-Notes/MaxScale-2.2.18-Release-Notes.md @@ -1,4 +1,4 @@ -# MariaDB MaxScale 2.2.18 Release Notes +# MariaDB MaxScale 2.2.18 Release Notes -- 2018-12-13 Release 2.2.18 is a GA release.