Ошибка курсора с postgresql, pgpool и php - PullRequest
1 голос
/ 11 мая 2011

Эй, я изо всех сил пытаюсь определить точную причину ошибки, которая появляется в нашей среде выпуска.Похоже, что в Google эта проблема не решается.

Это сообщение об ошибке, которое мы получаем:

SQLSTATE [34000]: Неверное имя курсора: 7 ОШИБКА: portal "" не существует

Ошибка появляется только тогда, когда мы используем подготовленные операторы PDO.

Это настройка для нашей среды выпуска:

  1. pgpool 3.0.1 (серверная часть postgresql находится в режиме потоковой репликации!)
  2. PHP 5.3.5
  3. PostgreSQL 9.0

Редактировать: архитектура 64-битная.

Та же ошибка не проявляется в нашей тестовой среде (Редактировать: забыли упомянуть, стандартная тестовая среда используетPostgresql 9.0 без pgpool).Таким образом, я подозреваю, что 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

Ответы [ 3 ]

0 голосов
/ 13 мая 2011

Я считаю, что у меня есть временная работа, и я инвестирую в поиск постоянного решения. Я работаю над кластером PG с высокой доступностью на Amazon EC2 и также столкнулся с этой проблемой.

Это происходит случайным образом для запросов, выполняемых с использованием блоков подготовки / выполнения DBI, когда DBI маршрутизируется через PGPool2 (3.0.3). Ошибки портала не возникают при удалении PGPool2, и мы напрямую используем Postgres 9.

Запускаем Perl, используя DBI и DBD :: PG. Общий фактор, похоже, PGPool2.

Одним из возможных решений, которое мы нашли, является установка ignore_leading_white_space '= false в pgpool.conf. Ошибки полностью исчезают для нас с этой опцией. К сожалению, у этого есть обратная сторона: возможна маршрутизация селекторов к мастеру, который должен быть сбалансирован по нагрузке, поэтому я не считаю его окончательным решением.

Пример кода, который генерирует эту проблему случайным образом:

$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;
0 голосов
/ 17 мая 2011

Я нашел решение. Оказывается, эта ошибка, которую мы испытываем, не существует в Pgpool-II 3.1 alpha2. Похоже, эта ошибка была исправлена ​​в марте после выпуска 3.0.3. Решение состоит в том, чтобы скачать релиз и собрать / установить вручную. Некоторые пути различны, например, путь конфигурации - / usr / local / etc /

Pgpool-II 3.1 alpha2 доступен здесь: http://pgfoundry.org/frs/?group_id=1000055

Возможно, в последнем дереве 3.0-Stable также есть исправление для этой проблемы. Я надеюсь протестировать экспорт из CVS сегодня вечером.

0 голосов
/ 11 мая 2011

Если бы вы могли продублировать проблему в своей тестовой среде, я без колебаний рекомендую запустить сервер с параметром -d (отладка).

Так как это не так, я просто напомню, что это вариант.

Параметры командной строки PostgreSQL

На этой странице есть пара «полувнутренних опций», которые могут помочь локализовать проблему. Может и нет.

...