Our solution follows a model which maintains most of the database manipulation logic in stored procedures.
When I upgraded from 10.2.9 to 10.2.11 I immediately got a failure in existing established code. This code also continues to function on 10.1.28 without problem.
I have prepared a database dump and a script which create a repeatable error.
to avoid shipping all of the code in the database I cut down the number of procedures shipped to a minimum, and the problem is now occurring in a different procedure so it looks like a general error rather than something that is specific to a partiiuclar error in our code.
I dont want to load up the database dump onto a public web site so can I provide that separately when this bug is picked up.
I have attached below the server.cnf file, the error log associated with the current repeatable crash plus a couple of other error logs from previous tests, plus the script to generate this problem.
- create a database ipswichdb;
- create a user ipswichdba and essentially grant them super user administrator status to the database.
- mysql -u ipswichdb -p <ip_2018_01_02_togo.sql
- mysql -u ipswichdba -p <ip_error_gen.sql
the error files below I generated by using first deleting my current error log and then doing a systemctl restart mariadb after loading the database and before running the test script.
Also I actually run the test script in Heidi, but I get the same effect whether its hedi or a more complex java app that I am running that normally triggers the problem.
Using the 2.1.2 java connector