The justification for this fix is as follows: - The patch is obviously safe (it does not touch code outside the functions mentioned in the description and those functions are already broken)
- The patch affects PostgreSQL library of PHP, no critical infrastructure or kernel - The bug may cause loss of user data due to losing database connection. Actual data loss depends on PHP application code running on top of the library and may or may not happen in practice. ** Description changed: - (I think the package should be php5-pgsql but launchpad wants me to use - "php5" for some reason.) + [Impact] pg_send_query() fails because of an implementation error if connection is done to remote host and query string is long OR transaction is very - long. + long. As a result, pg_send_query() is too unstable to be used at all if + the connection is made to any other host but 'localhost'. The problem is caused by the implementation not following the PostgreSQL documentation at http://www.postgresql.org/docs/9.1/static/libpq- async.html#LIBPQ-PQFLUSH "PQflush: [...] After sending any command or data on a nonblocking connection, call PQflush. [...]" Related PHP Bug: https://bugs.php.net/bug.php?id=65015 Patch: https://bugs.php.net/patch-display.php?bug_id=65015&patch=pg_send_query_flush_buffer.patch&revision=latest + + [Test Case] + Test script (from PHP bug): --- $len = 100000; // This may need to be increased, depending on db server. $sql = "select 1" . str_repeat(' ', $len - 8); $con = pg_connect('host=db-host.example.com dbname=postgres user=postgres password=password'); pg_send_query($con, $sql); pg_get_result($con); --- Note that the test script only fails if host is remote (connected using TCP/IP). + + [Regression Potential] + + Calling PQFlush() may cause some additional overhead for the cases where + flushing does not need to be done (the cases that happen to work as is). + The patch only touches functions pg_send_query() and + pg_send_query_params(), so any possible regression should affect only + those methods. Both these methods suffer from the same issue and are + already too broken to be used in production environment, unless the + connection is made to 'localhost'. + + The documentation of PQFlush() says "Attempts to flush any queued output + data to the server. Returns 0 if successful (or if the send queue is + empty), -1 if it failed for some reason, or 1 if it was unable to send + all the data in the send queue yet (this case can only occur if the + connection is nonblocking)." Calling PQFlush() should be okay for + blocking connections, too. In addition, the referenced patch does not + even touch that code. Source: http://www.postgresql.org/docs/9.1/static + /libpq-async.html + + [Other Info] ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: php5-pgsql 5.3.10-1ubuntu3.7 ProcVersionSignature: Ubuntu 3.8.0-27.40~precise3-generic 3.8.13.4 Uname: Linux 3.8.0-27-generic x86_64 ApportVersion: 2.0.1-0ubuntu17.4 Architecture: amd64 Date: Wed Sep 4 15:22:25 2013 InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1) MarkForUpload: True SourcePackage: php5 UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: [Impact] pg_send_query() fails because of an implementation error if connection is done to remote host and query string is long OR transaction is very long. As a result, pg_send_query() is too unstable to be used at all if the connection is made to any other host but 'localhost'. The problem is caused by the implementation not following the PostgreSQL documentation at http://www.postgresql.org/docs/9.1/static/libpq- async.html#LIBPQ-PQFLUSH "PQflush: [...] After sending any command or data on a nonblocking connection, call PQflush. [...]" Related PHP Bug: https://bugs.php.net/bug.php?id=65015 Patch: https://bugs.php.net/patch-display.php?bug_id=65015&patch=pg_send_query_flush_buffer.patch&revision=latest [Test Case] Test script (from PHP bug): --- $len = 100000; // This may need to be increased, depending on db server. $sql = "select 1" . str_repeat(' ', $len - 8); $con = pg_connect('host=db-host.example.com dbname=postgres user=postgres password=password'); pg_send_query($con, $sql); pg_get_result($con); --- Note that the test script only fails if host is remote (connected using TCP/IP). [Regression Potential] - Calling PQFlush() may cause some additional overhead for the cases where + Calling PQflush() may cause some additional overhead for the cases where flushing does not need to be done (the cases that happen to work as is). The patch only touches functions pg_send_query() and pg_send_query_params(), so any possible regression should affect only those methods. Both these methods suffer from the same issue and are already too broken to be used in production environment, unless the connection is made to 'localhost'. - The documentation of PQFlush() says "Attempts to flush any queued output + The documentation of PQflush() says "Attempts to flush any queued output data to the server. Returns 0 if successful (or if the send queue is empty), -1 if it failed for some reason, or 1 if it was unable to send all the data in the send queue yet (this case can only occur if the - connection is nonblocking)." Calling PQFlush() should be okay for + connection is nonblocking)." Calling PQflush() should be okay for blocking connections, too. In addition, the referenced patch does not - even touch that code. Source: http://www.postgresql.org/docs/9.1/static - /libpq-async.html + even touch that code. + + Source: http://www.postgresql.org/docs/9.1/static/libpq-async.html + Source: http://www.postgresql.org/message-id/6qy9iqwesu....@abnoba.intevation.de + [Other Info] ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: php5-pgsql 5.3.10-1ubuntu3.7 ProcVersionSignature: Ubuntu 3.8.0-27.40~precise3-generic 3.8.13.4 Uname: Linux 3.8.0-27-generic x86_64 ApportVersion: 2.0.1-0ubuntu17.4 Architecture: amd64 Date: Wed Sep 4 15:22:25 2013 InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1) MarkForUpload: True SourcePackage: php5 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1220677 Title: pg_send_query(): Cannot set connection to blocking mode To manage notifications about this bug go to: https://bugs.launchpad.net/php/+bug/1220677/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
