Ошибка курсора с postgresql, pgpool и php

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

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

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

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

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

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

Изменить: архитектура 64-битная.

Та же самая ошибка не проявляется в нашей тестовой среде (Edit: забыл упомянуть, стандартная тестовая среда использует 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 ответа

Решение

Я нашел решение. Оказывается, эта ошибка, которую мы испытываем, не существует в 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 tree также имеет исправление для этой проблемы. Я надеюсь проверить экспорт из CVS позже сегодня вечером.

Источник

Я считаю, что у меня есть временная работа, и я инвестирую в поиск постоянного решения. Я работаю над кластером 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;
Источник

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

Поскольку это не так, я просто напомню, что это вариант.

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

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

Источник
Другие вопросы по тегам