postgresql，pgpool和php的光标错误 - Cursor error with postgresql, pgpool and php

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

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

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

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

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

最新的 3.0-Stable 树也可能修复了此问题。我希望今晚晚些时候测试CVS的导出。

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

既然不是这样，我只想提醒你，这是一种选择。

PostgreSQL 命令行选项

在该页面上，有几个"半内部选项"可能有助于隔离问题。未必。

我相信

我有一个临时的工作，并致力于寻找一个永久的解决方案。我正在 Amazon EC2 上开发高可用性 PG 集群，也遇到了这个确切的问题。

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

我们使用DBI和DBD：:P G运行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;