From:             mike at ecommerce dot com
Operating system: any
PHP version:      4.3.10
PHP Bug Type:     PostgreSQL related
Bug description:  Misplaced "Cannot set connection to blocking mode" at end of 
output

Description:
------------
Problem Description:
I have an issue with a functionality in the function
_rollback_transactions defined in ext/pgsql/pgsql.c. This function is
responsible to rollback all transaction that are currently open in
persistent database connections, so those transactions do not leak over to
following scripts.

Before it sends any commands over the connection, it does the following:

if (PQ_SETNONBLOCKING(link, 0)) {
    php_error_docref("ref.pgsql" TSRMLS_CC, E_NOTICE, "Cannot set
connection to blocking mode");
    return -1;
}

When this "Cannot set connection to blocking mode" error is raised, then
in almost all cases it is because the connection to the database server is
broken, maybe because the PostgreSQL server was restarted, or the network
connection to it broke.

The problem is not the error message, because if something is wrong with
the database connection, it is correct to print an error (or to call the
error handler).

The problem is that in this special case this error message is not
displayed in the script that opened the database connection, but rather in
the first script this is run after the persistent connection broke. This
can be a script that is executed sometime afterwards - maybe a long time
afterwards, maybe in a script that never opened a database connection.
Basically it could occur in scripts that would normally not cause an error
at all. My point is that cause and effect of the error are disconnected.

Real-Life example:
The company i work for has this problem currently in one of our
applications. We use persistent connections to a PostgreSQL database over
an unreliable internet connection, that breaks every now and then.
Normally, this is not a big deal, because we have local database caches
which is used as a failsafe solution, and all scripts are programmed in a
way to watch out for database errors and automatically re-connect to this
failsafe database without the user noticing a thing. All fine until now.

But every time the internet connection - and therefore the connection to
the remote database - breaks, all other PHP applications that are hosted
on the same server, which do use different databases or do not use a
database at all, suddenly print the message "Notice: (null)(): Cannot set
connection to blocking mode in Unknown on line 0" at the end of the
output.

Suggested Resolution:
Remove the line that calls php_error_docref to raise the error. The
database link is removed anyway from the list of persistent connections,
due to the "return -1;" directly afterwards.

I am aware that there are other solutions, like adjusting
"error_reporting" not to include E_NOTICE, or to turn off
"display_errors". Or to install a custom error handler that silently
ignores this error.

However, after carefully considering all options, IMHO i think that
removing the line in the PHP sources that raises the error is the cleanest
solution, with the main argument for it being that cause and effect of the
problem do not directly relate. That means the script that prints the
error and/or handles the error in its custom error handler may have
nothing to do with the broken database connection.


Actual result:
--------------
Notice: (null)(): Cannot set connection to blocking mode in Unknown on
line 0

-- 
Edit bug report at http://bugs.php.net/?id=31411&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=31411&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=31411&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=31411&r=trysnapshot51
Fixed in CVS:                http://bugs.php.net/fix.php?id=31411&r=fixedcvs
Fixed in release:            http://bugs.php.net/fix.php?id=31411&r=alreadyfixed
Need backtrace:              http://bugs.php.net/fix.php?id=31411&r=needtrace
Need Reproduce Script:       http://bugs.php.net/fix.php?id=31411&r=needscript
Try newer version:           http://bugs.php.net/fix.php?id=31411&r=oldversion
Not developer issue:         http://bugs.php.net/fix.php?id=31411&r=support
Expected behavior:           http://bugs.php.net/fix.php?id=31411&r=notwrong
Not enough info:             
http://bugs.php.net/fix.php?id=31411&r=notenoughinfo
Submitted twice:             
http://bugs.php.net/fix.php?id=31411&r=submittedtwice
register_globals:            http://bugs.php.net/fix.php?id=31411&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=31411&r=php3
Daylight Savings:            http://bugs.php.net/fix.php?id=31411&r=dst
IIS Stability:               http://bugs.php.net/fix.php?id=31411&r=isapi
Install GNU Sed:             http://bugs.php.net/fix.php?id=31411&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=31411&r=float
No Zend Extensions:          http://bugs.php.net/fix.php?id=31411&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=31411&r=mysqlcfg

Reply via email to