mysql_common.c:gw_send_change_user_to_backend creates new authentication message which is to be sent to backend. GWBUG type flags were not copied from original GWBUF to new one. Thus the information that this is a session command was lost and it was processed in a wrong way. Especially replies were all routed back to client which caused misbehavior.
MySQL Auth with dbname check
Unknown database ‘xxxxx’ is returned to client
Proper error number is still missing and also com_change_user need to
be fixed
Client flags are now copied to each backend and used in their connections.
log_manager.cc: fixed string allocation where one byte was missing.
mysql_client.c: fixed string allocation where one byte was missing.
mysql_client.c, added functions create_auth_fail_str, and get_username_from_auth to implement creation of similar error msg with MySQL. There is one difference left, because MaxScale prints IP address instead of hostname in error message.
Also changed 'authorization failed' to 'access denied'
mysql_common.c: fixed memory leak in gw_receive_backend_auth, and replaced error code '2800' with '28000'.
readconnroute.c:handleError didn't set *succp pointer so uninitialized value was used in caller's context.
makefile.inc: added -lm to linker flags
mysql_backend.c: added a few comments
query_classifier.cc: added function for printing combined query type from a bit field.
query_classifier.h: identify query types SHOW DATABASE, and SHOW TABLES to make log entries more understandable.
mysql_common.c: moved some trace log commands to debug log.
readwritesplit.c: moved some trace logs to debug log, added trace log commands to gather routing, query type and session information to one log entry.
skygw_debug.h: added string macros for several query and hint types.
Execution of session commands failed because session commands and normal sql statements were executed in a wrong order if backend was executing previous session command while new sql stmt was routed to that backend. There was a window where ordering went wrong.
It is possible that one normal sql stmt arrives while previous sescmds are still being executed.
Introduced a new member in backend_ref_t structure, bref_pending_cmd where new sql stmt pointer is stored in that case. When sescmds are executed completely, that command is automatically executed next.
