|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78179 MariaDB 10.3 broke mysqli::begin_transaction()
Submitted: 2019-06-18 19:27 UTC Modified: 2019-08-08 14:11 UTC
Avg. Score:4.0 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: david dot bergeron5 at usherbrooke dot ca Assigned:
Status: Closed Package: MySQLi related
PHP Version: Irrelevant OS: Debian 9
Private report: No CVE-ID: None
 [2019-06-18 19:27 UTC] david dot bergeron5 at usherbrooke dot ca
MariaDB Version 10.3.15-MariaDB-1:10.3.15+maria~stretch
PHP Version: PHP version: 7.0.33-0+deb9u3

With MariaDB 10.3 they remove the innoDB version reporting.

I think this is due to this issue in MariaDB.

So when you do a 

You receive a "PHP Warning:  mysqli::begin_transaction(): This server version doesn't support 'READ WRITE' and 'READ ONLY'. Minimum 5.6.5 is required in /var/www/html/..."

Test script:

$db = new mysqli( $host, $username, $password, $database);

Expected result:
Should not say that this doesn't support 'READ WRITE'.

Actual result:
PHP Warning:  mysqli::begin_transaction(): This server version doesn't support 'READ WRITE' and 'READ ONLY'. Minimum 5.6.5 is required in /var/www/html/dbtest.php on line 8


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-06-26 03:11 UTC] 4275556 at qq dot com
I met the same problem just now.
mariadb 10.4
Centos 7

 mysqli::begin_transaction(): This server version doesn't support 'READ WRITE' and 'READ ONLY'. Minimum 5.6.5 is required in /data/BPlatform/common/lock/MySqliLock.php on line 53

it was good before upgrading to mariadb 10.4 (was mysql 5.6)
 [2019-07-21 16:28 UTC] duckwebdev at gmail dot com
Same issue even when using two different configurations. It would appear Oracle made their own bug report and properly fixed their code too:

Configuration 1:
MariaDB Version: 10.1.35
PHP version: 7.2.16
OS: CentOS 7

Configuration 2:
MariaDB Version: 10.1.37
PHP version: 7.2.12
OS: Win10

Follow in MariaDB's footsteps and check for the fake version number, then remove if it exists. See MariaDB's sql-common/client.c:
 [2019-07-21 17:43 UTC]
-Status: Open +Status: Analyzed
 [2019-07-21 17:43 UTC]
What does mysqli_get_server_version($mysqli) or $mysqli->server_version return? 50505 I assume? And this has been the case since MariaDB 10.0, right? It's not new?

Because, to fill in the blanks that @duckwebdev saw, MariaDB returns a half-hardcoded version number (string) like "5.5.5-10.5.0". Which is a nuisance - it should be faking the corresponding MySQL version, not a fixed 5.5.5. Which is to say nothing about how hacky this was to fix the original problem. Sigh.

PHP could detect the magic "5.5.5-" string as their client does, but the truth is that since 10.0 their versioning scheme is incompatible with MySQL's. Like how 10.0 is based on the 5.6 series and so does not support 5.7 (or future) features, even though 10.0 >= 5.7. Which means to get it absolutely right PHP would need different version number checks; for example, transactions' READ WRITE/READ ONLY requires MySQL 5.6.5, which presumably will be somewhere (I can't find where) in the MariaDB 10.0 *and* 10.1 series. Double sigh.

...why couldn't they have done it properly like Percona...

Or... we could sweep the issue under the rug and remove version checks for older stuff - after all 5.6.5 was released April 2012, which is back in the PHP 5.3 era.
 [2019-07-24 12:03 UTC]
Server version: 10.1.38-MariaDB-0+deb9u1 Debian 9.8

var_dump($mysqli->server_version); // int(50505)

This also causes 8 test to fail.
 [2019-07-24 13:35 UTC]
The following pull request has been associated:

Patch Name: Fix #78179: MariaDB server version incorrectly detected
On GitHub:
 [2019-08-02 14:46 UTC]
Automatic comment on behalf of
Log: Fix #78179: MariaDB server version incorrectly detected
 [2019-08-02 14:46 UTC]
-Status: Analyzed +Status: Closed
 [2019-08-02 14:48 UTC]
-Assigned To: +Assigned To: cmb
 [2019-08-08 13:27 UTC]
-Status: Closed +Status: Wont fix
 [2019-08-08 13:27 UTC]
mysqlnd implements the MySQL Client/Server protocol. If MariaDB doesn't follow the reference implementation then this is a problem of MariaDB, not of mysqlnd.
I am going to revert this patch.
 [2019-08-08 13:36 UTC] david dot bergeron5 at usherbrooke dot ca
A little bit harsh but I understand.

My only question than is why is mysqlnd is not doing what We ask it to do, not using transaction if MariaDB support it at version 10.3 ?

From what I can know of the protocol there is nothing in the protocol that say check the version number before doing a LOCK. 

Not that I am a fan of MariaDB to change the versioning schema, but there probably should be a other way in MySQL and MariaDB to find what features is available in the current server.
 [2019-08-08 14:00 UTC] david dot bergeron5 at usherbrooke dot ca
I don't know if this could help.

If I do a HELP 'lock'; It return this.
And we can see what is supported by the current version of the server.

We should probably ask MySQL and MariaDB to have a more easy to parse definition of theirs statements.


    tbl_name [[AS] alias] lock_type
    [, tbl_name [[AS] alias] lock_type] ...



MySQL enables client sessions to acquire table locks explicitly for the
purpose of cooperating with other sessions for access to tables, or to
prevent other sessions from modifying tables during periods when a
session requires exclusive access to them. A session can acquire or
release locks only for itself. One session cannot acquire locks for
another session or release locks held by another session.

Locks may be used to emulate transactions or to get more speed when
updating tables. This is explained in more detail later in this

LOCK TABLES explicitly acquires table locks for the current client
session. Table locks can be acquired for base tables or views. You must
have the LOCK TABLES privilege, and the SELECT privilege for each
object to be locked.

For view locking, LOCK TABLES adds all base tables used in the view to
the set of tables to be locked and locks them automatically. If you
lock a table explicitly with LOCK TABLES, any tables used in triggers
are also locked implicitly, as described in

UNLOCK TABLES explicitly releases any table locks held by the current
session. LOCK TABLES implicitly releases any table locks held by the
current session before acquiring new locks.

Another use for UNLOCK TABLES is to release the global read lock
acquired with the FLUSH TABLES WITH READ LOCK statement, which enables
you to lock all tables in all databases. See [HELP FLUSH]. (This is a
very convenient way to get backups if you have a file system such as
Veritas that can take snapshots in time.)

 [2019-08-08 14:11 UTC]
-Assigned To: cmb +Assigned To:
 [2020-07-21 07:35 UTC] daniel at mariadb dot org
The following pull request has been associated:

Patch Name: Fix #78179: mysqli/mysqlnd transaction extensions
On GitHub:
 [2020-09-18 13:33 UTC]
Automatic comment on behalf of
Log: Fix #78179: mysqli/mysqlnd transaction extensions
 [2020-09-18 13:33 UTC]
-Status: Wont fix +Status: Closed
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Thu Sep 28 18:01:24 2023 UTC