| 2013-10-11 10:30:49 |
Mikko Rantalainen |
description |
(I think the package should be php5-pgsql but launchpad wants me to use "php5" for some reason.)
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.
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 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).
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) |
[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 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) |
|
| 2013-10-11 10:36:04 |
Mikko Rantalainen |
description |
[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 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) |
[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 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
Source: http://www.postgresql.org/message-id/6qy9iqwesu.fsf@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) |
|
