Use `grep -E` instead of `egrep` as `egrep` now emits a warning.
```
t/opt_report_checkpoints.t: failed
--- t/opt_report_checkpoints.t
+++ t/opt_report_checkpoints.t.err
@@ -8,6 +8,7 @@
> fi
$ sysbench ${SBTEST_SCRIPTDIR}/oltp_read_write.lua --db-driver=mysql --mysql-dry-run --time=3 --events=0 --report-checkpoints=1,2 run | egrep '(Checkpoint report|SQL statistics)'
+ egrep: warning: egrep is obsolescent; using grep -E
[ 1s ] Checkpoint report:
SQL statistics:
[ 2s ] Checkpoint report:
```
```
$ echo | egrep 'abc'
egrep: warning: egrep is obsolescent; using grep -E
$ grep --version
grep (GNU grep) 3.8
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others; see
<https://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
```
MySQL may return multiple result sets from a call to a stored
procedure (the CALL statement), or when multiple queries are specified
in a single client request. The application is supposed to process those
multiple result sets one by one with calls to `mysql_next_result()`, or
its prepared statements counterpart, `mysql_stmt_next_result()`.
Additionally, there is the `mysql_more_results()` call which allows the
application to check if more result sets are available and works for
both regular queries and prepared statements API.
One way to handle multiple results in sysbench would be consuming all
result sets silently in the MySQL driver, but that would make it
impossible for scripts to get access to individual result sets returned
by a stored procedure.
Now sysbench exposes those MySQL client API calls to the SQL API, so it
is up to the script authors to handle multiple result sets when either
stored procedures are used in a benchmark script, or multiple queries
are passed to `sql_connection:query()`:
- sql_connection:next_result()
- sql_connection:more_results()
- sql_statement:next_results()
Here is an example how multiple results can be handled in a benchmark
script:
```lua
local rs = con:query([[CALL p1("foo")]])
while rs ~= nil do
-- handle the result set
rs = con:next_result()
end
```
Here is a prepared statement example:
```lua
stmt = con:prepare("CALL p1(?)")
param = stmt:bind_create(sysbench.sql.type.CHAR, 10)
stmt:bind_param(param)
param:set("bar")
rs = stmt:execute()
while rs ~= nil do
rs = stmt:next_result()
end
```
Fixes GH-304.
Remove the legacy 'special' distribution, because it was unscientific
and hard to explain.
Pareto and Zipfian distributions provide more clearly defined
alternatives.
api_sql_mysql.t failed if SBTEST_MYSQL_ARGS included an explicit
specification of '--mysql-socket', in which case ignores --mysql-host
and asssumes 'localhost'.
If the MySQL driver is available and --db-driver option was explicitly
specified, assume MySQL and don't compain about multiple DB drivers
being available.
That was a popular request and is likely what most sysbench users want.
The problem with MySQL 5.7+ client libraries was that there was no way
to disable SSL usage from the sysbench command line, because the client
library defaults to MYSQL_OPT_SSL_MODE = SSL_MODE_REQUIRED, even if
--mysql-ssl is not used. So the only way to disable it was disabling SSL
on the server.
Now --mysql-ssl behaves like the --ssl-mode option in MySQL client
utilities. It accepts the following values (with "disabled" being the
default):
disabled, preferred, required, verify_ca, verify_identity.
When sysbench is built With pre-5.6 MySQL client libraries or MariaDB
client libraries, where support for SSL modes is not available,
--mysql-ssl behavior is not affected by this change, i.e. it remains a
boolean variable accepting the on/off values, with "off" being the
default.
Replace hard-coded values for client SSL path names with driver options,
at the same time making it possible to skip those options even when
--mysql-ssl is used.
