1

ねえ、リリース環境で発生したエラーの正確な原因を特定するのに少し苦労しています。Google では、この特定のエラーをあまり扱っていないようです。

これは私たちが得ているエラーメッセージです:

SQLSTATE[34000]: 無効なカーソル名: 7 エラー: ポータル "" が存在しません

エラーは、PDO プリペアド ステートメントを使用している場合にのみ表示されます。

これは、リリース環境のセットアップです。

  1. pgpool 3.0.1 (postgresql バックエンドはストリーミング レプリケーション モードです!)
  2. PHP5.3.5
  3. PostgreSQL 9.0

編集: アーキテクチャは 64 ビットです。

私たちのテスト環境では同じエラーは発生しません (編集: 言及するのを忘れていました。標準のテスト環境では、pgpool なしで Postgresql 9.0 を使用しています)。したがって、pgpool が少なくとも部分的に疑わしいと思われます。

このエラーの考えられる原因を知っている人はいますか?

編集: OK、エラーの原因となるコードの例を次に示します。

$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

私は一時的な回避策があると信じており、恒久的な解決策を見つけることに投資しています。私はAmazonEC2で高可用性PGクラスターに取り組んでおり、この正確な問題にも遭遇しました。

これは、DBIがPGPool2（3.0.3）を介してルーティングされるときに、DBIのprepare/executeブロックを使用して実行されるクエリに対してランダムに発生します。PGPool2が削除され、Postgres 9を直接使用する場合、ポータルエラーは発生しません。

DBIとDBD::PGを使用してPerlを実行します。公約数はPGPool2のようです。

私たちが見つけた1つの可能な解決策は、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 に答える
0

テスト環境で問題を再現できる場合は、-d (デバッグ) オプションを指定してサーバーを実行することをお勧めします。

そうではないので、それがオプションであることを思い出させてください。

PostgreSQL コマンド ライン オプション

そのページには、問題の特定に役立つ可能性のある「半内部オプション」がいくつかあります。ではないかもしれない。

于 2011-05-11T12:36:41.527 に答える