php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66528 No PDOException or errorCode if database becomes unavailable before PDO::commit
Submitted: 2014-01-21 10:09 UTC Modified: 2020-10-28 09:00 UTC
Votes:72
Avg. Score:4.7 ± 0.9
Reproduced:45 of 53 (84.9%)
Same Version:17 (37.8%)
Same OS:15 (33.3%)
From: fk at florian-kaiser dot net Assigned: nikic (profile)
Status: Closed Package: PDO MySQL
PHP Version: 7.3 OS: Debian Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: fk at florian-kaiser dot net
New email:
PHP Version: OS:

 

 [2014-01-21 10:09 UTC] fk at florian-kaiser dot net
Description:
------------
If the database resource (e.g. the MySQL-Server) becomes unavailable before a PDO::commit(), it emits a warning only, e.g. "MySQL server has gone away" or "Error reading result set's header" and code execution proceeds.

Additionally, neither PDO::errorCode() nor PDO::errorInfo() are set. Inspected just after the warnings both suggest that everything is perfectly fine. This is unacceptable.

I dont really like the handling of that situation at all. Since warnings will only get logged in production mode and code execution proceeds without knowing there actually was an error (happens with PDO::commit() that returns true regardless), this will for sure give some developer lots of headaches. Together with that other bug in PDO::commit(), current implementation makes it _impossible_ to reliably check if a PDO::commit() call failed.

Please note that using PDO::query('commit'); instead of PDO::commit() actually respects PDO::ATTR_ERRMODE and behaves in a more proper way, e.g. if set to PDO::ERRMODE_EXCEPTION actually throws a PDOException and PDO::errorCode/errorInfo will be set accordingly. Warnings though will show regardless (when you're on it, fix that as well, please).
This is the only workaround in current implementations to reliably use transactions with PDOMysql.

A severe interruption like connection loss to database should be treated with the same error handling that is used when establishing the connection. Better still, just do it like PDO::query, honor PDO::ATTR_ERRMODE or throw a PDOException per default. No matter what will be implemented, PDO::errorCode and PDO::errorInfo must be fixed so they reflect errors that occur when using PDO::commit().

Test script:
---------------
<?php
$dbh = new PDO('mysql:dbname=test;host=127.0.0.1;charset=UTF8', 'testuser', '');
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// prepare table for test
$dbh->query('DROP TABLE IF EXISTS importantdata');
$dbh->query('create table test.importantdata (a int) engine=innodb');

try {

	$dbh->beginTransaction();
	$dbh->query('insert into importantdata (a) VALUES (1), (2)');

	sleep(20); // shut down mysql-server
	
	$dbh->commit();

} catch (PDOException $e) {
	exit($e->getMessage());
}
print_r($dbh->errorInfo());
echo 'I should never get here';
?>

Expected result:
----------------
"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away" 
[... Script execution stopped]


Actual result:
--------------
Warning: PDO::commit(): MySQL server has gone away in /tmp/test.php on line 16

Warning: PDO::commit(): Error reading result set's header in /tmp/test.php on line 16
Array
(
    [0] => 00000
    [1] => 
    [2] => 
)

I should never get here
[... Script execution proceeds]

Patches

commit-einfo (last revision 2019-04-28 13:50 UTC by cmb@php.net)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-20 21:05 UTC] fk at florian-kaiser dot net
It's now over 3 years since my initial bug report. Bug is still present in latest PHP7.1 making it _impossible_ to use PDO::commit() in a reliable fashion.

I really don't understand why a bug this severe is being kept open this long. It would really help us developers if this gets fixed soon.
 [2019-03-16 15:55 UTC] jonathan dot lopes at educlever dot com
The same lack of PDOException or error is visible for a conflict resolution on the PDO::COMMIT in a galera environment : no "Deadlock found when trying to get lock; try restarting transaction" feedback.
 [2019-04-27 14:44 UTC] fk at florian-kaiser dot net
-PHP Version: 5.5.8 +PHP Version: 7.3
 [2019-04-27 14:44 UTC] fk at florian-kaiser dot net
Any news on this? Bug is still present in latest PHP 7.3, it's really time this gets fixed. What can we do to speed this up?
 [2019-04-28 13:50 UTC] cmb@php.net
The following patch has been added/updated:

Patch Name: commit-einfo
Revision:   1556459438
URL:        https://bugs.php.net/patch-display.php?bug=66528&patch=commit-einfo&revision=1556459438
 [2019-04-28 13:54 UTC] cmb@php.net
Something like the commit-einfo patch would set the error info for
commits, but rollbacks and autocommits and maybe more seem to need
an analogous fix.

Wrt. additional warnings: I'm not sure how to handle these.  Maybe
mysqlnd shouldn't raise them in the first place.
 [2020-10-28 09:00 UTC] nikic@php.net
-Assigned To: +Assigned To: nikic
 [2020-10-28 11:19 UTC] nikic@php.net
Automatic comment on behalf of nikita.ppv@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=68dcaa29d8a2d51f0fed5fde9f3543a1338bfe44
Log: Fixed bug #66528
 [2020-10-28 11:19 UTC] nikic@php.net
-Status: Assigned +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 07:01:29 2024 UTC