php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #12229 implicit_flush (off) causes mysql to see into the future
Submitted: 2001-07-18 07:22 UTC Modified: 2002-01-05 16:46 UTC
From: php-man at qcn dot com dot au Assigned:
Status: Closed Package: MySQL related
PHP Version: 4.0.6 OS: RedHat 7.1
Private report: No CVE-ID: None
 [2001-07-18 07:22 UTC] php-man at qcn dot com dot au
I'll be the first to admit that this is weird ... but, after 11hours of debugging and recompiling I can safely say that while implicit_flush is off, mysql_query returns some odd (pre-emptive) results;


I have run an old database system (php3.0.12/mysql3.22.26a (sitting on RH6.0)) for a couple of years .. I wanted to put that onto a new RH7.1 box (php4.04pl1-9/mysql3.23.36-1).  Whith the same database structure, and the same
php code (bar the mysql_affected_rows() "link id" mod) I was seeing future mysql updates being entered into the database before current php decisions, ie;

Table "tbl" has 1 record.  In that record, field "fldx"=0, field "fldt"=0.

if we query the database, in one instance, and do nothing more;
          select * from tbl, echo field "fldx"
.. the screen output is the value 0.


if we add to that php program/script a function call to a function containing further mysql queries - including updates to the field we echo at the top of this script (above);
     function whatever (condition parameters) {
          $time = 995454806
          update tbl set fldt=$time where (conditions) and fldt=0
          if affected rows > 0  {
               select * from tbl where (conditions)
               if number rows > 0  {
                    fetch array (to retrieve fldx)
                    if fldx == 2 {
                          delete from tbl where (conditions)
                          (interim work on other tables)
                          return
                     } else {
                          update tbl set fldx=2 where (conditions)
                          (interim work on other tables)
                          update tbl set fldt=0 where (conditions) and fldt=$time
                          return
                     }
                }
            }
            return
         }


then the onscreen output for fldx is "2".

It is as though we had gone through the program with the stored fldx value of "0", switching through the conditions appropriately, then updating our record (fldx) with a "2", before we proceed through the php (from the top),
outputting our "2" then randomly tripping condition 1 (no affected rows), or randomly tripping condition fldx==2, 
causing the record to be prematurely deleted, or randomly (far less frequently than the prior) occuring correctly.

 ... almost as if the output caching was occuring *between* PHP and MySQL ... not between PHP and the User .. (?)

Since I had thought it was version problems with PHP/MySQL, I have compiled up and am now running php4.06 and mysql3.23.39 -- where the problem persisted. I have since verified that the /etc/php.ini setting "implicit_flush" when set to "on" under the newer software, does return my code to the former php3/expected logic.

Very strange indeed.




Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-07-18 08:46 UTC] php-man at qcn dot com dot au
In addition;

  After removing debugging code (which included a top-of-script database open, loop'd fetch-array, close ... a heap
of "echo"s with relevant stages/values .. and a few var_dumps) the implicit_flush=On is no longer keeping the script predictable.  I can't believe I'm the only person experiencing these difficulties/bugs (if they are legitimate) ... have I done something catastrophically wrong?  I would suspect a php error (on my part) if the error was consistant/predictable .. but the only time this has been predictable has been either under php3 (where the code has existed for 2years) or with my own debug code and implicit_flush on in php4 (which I now can no longer reproduce) ... very frustrating.

Any help/info appreciated ... I can run test code if it will help.

 [2001-12-14 14:50 UTC] sander@php.net
Can you:
-test this with 4.1.0
-provide a short and self-contained samplescript which shows the problem?
 [2002-01-05 16:46 UTC] lobbin@php.net
No feedback. Closing.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 19:01:33 2024 UTC