MaxScale Release Notes 1.0.3 GA This document details the changes in version 1.0.3 since the release of the 1.0.2 Release Candidate of the MaxScale product. # New Features No new features have been introduced since the released candidate was released. # Bug Fixes A number of bug fixes have been applied between the 0.6 alpha and this alpha release. The table below lists the bugs that have been resolved. The details for each of these may be found in bugs.mariadb.com.
ID | Summary |
644 | Buffered that were cloned using the gwbuf_clone routine failed to initialise the buffer lock structure correctly. |
643 | Recursive filter definitions in the configuration file could cause MaxScale to loop |
665 | An access to memory that had already been freed could be made within the MaxScale core |
664 | MySQL Authentication code could access memory that had already been freed. |
673 | MaxScale could crash if it had an empty user table and the MaxAdmin show dbusers command was run |
670 | The tee filter could lose statement on the branch service if the branch service was significantly slower at executing statements compared with the main service. |
653 | Memory corruption could occur with extremely long hostnames in the mysql.user table. |
657 | If the branch service of a tee filter shutdown unexpectedly then MaxScale could fail |
654 | Missing quotes in MaxAdmin show dbusers command could cause MaxAdmin to crash |
677 | A race condition existed in the tee filter client reply handling |
658 | The readconnroute router did not correctly close sessions when a backend database failed |
662 | MaxScale startup hangs if no backend servers respond |
676 | MaxScale writes a log entry, "Write to backend failed. Session closed." when changing default database via readwritesplit with max_slave_connections != 100% |
650 | Tee filter does not correctly detect missing branch service |
645 | Tee filter can hang MaxScale if the read/write splitter is used |
678 | Tee filter does not always send full query to branch service |
679 | A shared pointer in the service was leading to misleading service states |
680 | The Read/Write Splitter can not load users if there are no databases available at startup |
681 | The Read/Write Splitter could crash is the value of max_slave_connections was set to a low percentage and only a small number of backend servers are available |