Question

嘿，我正在努力确定在我们的发布环境中出现的错误的确切原因。似乎没有太多关于谷歌这个特殊错误的处理。

这是我们收到的错误消息：

SQLSTATE [34000]：游标名称无效： 7错误：门户网站“”不存在

当我们使用PDO预处理语句时，只会弹出错误。

这是我们发布环境的设置：

pgpool 3.0.1（postgresql后端处于流复制模式！）
PHP 5.3.5
PostgreSQL 9.0

编辑：架构为64位。

我们的测试环境中没有显示相同的错误（编辑：忘记提及，标准测试环境使用不带pgpool的Postgresql 9.0）。因此，我被怀疑pgpool至少部分是可疑的。

有谁知道这个错误的可能原因是什么？

编辑：好的，这是导致错误的代码类型的示例。

$sql = 'SELECT * ';
$sql .= 'FROM "myTable" as "myStuff" ';
$sql .= 'WHERE "myTable"."status" = 1 ';
$sql .= 'AND "myTable"."myTableId" = :tableId ';
$sth = $this->_db->prepare($sql);
$sth->bindParam(':tableId', $tableId, PDO::PARAM_INT);
$sth->execute();

编辑：一些日志文件输出;

PostgreSQL的：

postgresql-Sun.log-129- ORDER BY "id" 
postgresql-Sun.log:130:ERROR:  portal "" does not exist
postgresql-Sun.log-131-ERROR:  prepared statement "pdo_stmt_00000011" does not exist
postgresql-Sun.log-132-STATEMENT:  DEALLOCATE pdo_stmt_00000011


postgresql-Mon.log-82-  where "id" = 32024
postgresql-Mon.log:83:ERROR:  portal "" does not exist
postgresql-Mon.log-84-ERROR:  prepared statement "pdo_stmt_00000002" does not exist
postgresql-Mon.log-85-STATEMENT:  DEALLOCATE pdo_stmt_00000002

pgpool：

LOG:   pid 22071: Replication of node:1 is behind 2080 bytes from the primary server (node:0)
LOG:   pid 22071: Replication of node:2 is behind 2080 bytes from the primary server (node:0)
LOG:   pid 13499: pool_send_and_wait: Error or notice message from backend: : DB node id: 0 backend pid: 8470 statement:  message: portal "" does not exist
LOG:   pid 13499: pool_send_and_wait: Error or notice message from backend: : DB node id: 0 backend pid: 8470 statement: DEALLOCATE pdo_stmt_00000003 message: prepared statement "pdo_stmt_00000003" does not exist

Answer 1

如果您可以在测试环境中复制问题，我会毫不犹豫地建议使用-d（调试）选项运行服务器。

由于情况并非如此，我只是提醒你，这是一个选择。

PostgreSQL command line options

在该页面上，有一些“半内部选项”可能有助于隔离问题。可能不会。

Answer 2

我相信我有一个临时的工作，并投入寻找永久的解决方案。我正在开发Amazon EC2上的高可用性PG集群，并且还遇到了这个问题。

当DBI通过PGPool2（3.0.3）路由时，对于使用DBI的准备/执行块执行的查询，它会随机发生。删除PGPool2时我们不会发生门户网站错误，我们直接使用Postgres 9。

我们使用DBI和DBD :: PG运行Perl。常见因素似乎是PGPool2。

我们发现的一个可能的解决方案是在pgpool.conf中设置'ignore_leading_white_space'= false。使用此选项设置时，错误完全消失。不幸的是，这确实有潜在的路由选择到主应应该负载平衡的缺点，因此我不认为它是最终的解决方案。

随机生成此问题的代码示例：

$sth = $dbh->prepare("SELECT * FROM TABLEX WHERE ID = ?" ) 
|| die "Can't prepare statement: " . $dbh->errstr;
$sth->execute($self->id) || die "Can't get inventory " . $dbh->errstr;

Answer 3

我找到了解决方案。原来我们遇到的这个错误在Pgpool-II 3.1 alpha2中不存在。看起来这个bug在3.0.3版本发布后于3月份修复。解决方案是手动下载发布和构建/安装。一些路径是不同的，例如配置路径是/ usr / local / etc /

Pgpool-II 3.1 alpha2可在此处获得： http://pgfoundry.org/frs/?group_id=1000055

最新的3.0-Stable树可能也解决了这个问题。我希望能在今晚晚些时候测试CVS的出口。

postgresql，pgpool和php的游标错误

3 个答案: