Description: ------------ When using the PEAR::DB package to access a database from a script that creates child processes using the pcntl_fork() function, the PEAR::DB connections for all processes (parent and children) when the first child process ends, even if the PEAR::DB objects/connections are recreated after the forking API call. This same behavior is NOT experienced if using the mysql_* API directly. Additional details may be found in the php-db archive: http://news.php.net/php.db/43467 http://news.php.net/php.db/43468 http://news.php.net/php.db/43469 http://news.php.net/php.db/43470 http://news.php.net/php.db/43462 http://news.php.net/php.db/43464 http://news.php.net/php.db/43465 Test script: --------------- Script using PEAR::DB http://headnut.org/~squirrel/forking-proof-of-concept-1.php.txt Script using mysql_* API http://headnut.org/~squirrel/forking-proof-of-concept-2.php.txt Expected result: ---------------- $ php forking-proof-of-concept-2.php Child process 2902 created Child process 2903 created Child process 2906 created Child process 2908 created Child process 2909 created Parent process waiting on child process 2902 Parent process detected child process 2902 is finished Parent process waiting on child process 2903 Parent process detected child process 2903 is finished Parent process waiting on child process 2906 Parent process detected child process 2906 is finished Parent process waiting on child process 2908 Parent process detected child process 2908 is finished Parent process waiting on child process 2909 Parent process detected child process 2909 is finished $ mysql -u test -ptest testdb mysql> select * from logs; +--------------------------------------------------------+ | message | +--------------------------------------------------------+ | Started parent process | | Child process 2902 started | | Child process 2906 started | | Child process 2903 started | | Child process 2908 started | | Parent process waiting on child process 2902 | | Child process 2909 started | | Child process 2902 ended | | Child process 2908 ended | | Child process 2909 ended | | Child process 2903 ended | | Child process 2906 ended | | Parent process detected child process 2902 is finished | | Parent process waiting on child process 2903 | | Parent process detected child process 2903 is finished | | Parent process waiting on child process 2906 | | Parent process detected child process 2906 is finished | | Parent process waiting on child process 2908 | | Parent process detected child process 2908 is finished | | Parent process waiting on child process 2909 | | Parent process detected child process 2909 is finished | | Parent process is finished | +--------------------------------------------------------+ 22 rows in set (0.00 sec) Actual result: -------------- $ php forking-proof-of-concept-1.php Child process 2887 created Child process 2888 created Child process 2889 created Child process 2890 created Child process 2892 created Parent process waiting on child process 2887 Parent process detected child process 2887 is finished Parent process waiting on child process 2888 Parent process detected child process 2888 is finished Parent process waiting on child process 2889 Parent process detected child process 2889 is finished Parent process waiting on child process 2890 Parent process detected child process 2890 is finished Parent process waiting on child process 2892 Parent process detected child process 2892 is finished $ mysql -u test -ptest testdb mysql> select * from logs; +----------------------------------------------+ | message | +----------------------------------------------+ | Started parent process | | Child process 2887 started | | Child process 2888 started | | Child process 2889 started | | Child process 2890 started | | Parent process waiting on child process 2887 | | Child process 2892 started | | Child process 2887 ended | | Child process 2888 ended | +----------------------------------------------+ 9 rows in set (0.00 sec)

The default behaviour of DB_mysql is that the new_link parameter in the mysql_connect call will be set to false, whereas the reproduce script which uses mysql_connect sets it to true. As a result, the reproduce script for PEAR::DB will attempt to reuse an existing connection even though persistent connections aren't explicitly enabled, and wackiness ensues. Changing the DSN in the reproduce script to 'mysql://test:test@localhost/testdb?new_link=true' fixes the problem for me, so I'm going to close this for now.