1

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

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

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

仅当我们使用 PDO 准备语句时才会弹出错误。

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

  1. pgpool 3.0.1（postgresql 后端处于流复制模式！）
  2. PHP 5.3.5
  3. 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
4

3 回答 3

0

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

既然情况并非如此，我只会提醒您这是一种选择。

PostgreSQL 命令行选项

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

于 2011-05-11T12:36:41.527 回答
0

我相信我有一个临时的工作，并投资于寻找一个永久的解决方案。我正在 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;
于 2011-05-13T01:43:55.277 回答
0

我找到了解决方案。原来我们遇到的这个错误在 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 的导出。

于 2011-05-17T17:15:26.947 回答