2013-11-22 1 views
4

В настоящее время выполняется простое приложение для синатра, использующее пассажира, и использование pgbouncer для объединения пулов в базу данных на том же сервере, что и приложение. В настоящее время я периодически получаю ошибку PG, что подготовленный оператор «a \ d» не существует.Подготовленное заявление не существует

 
A PG::Error occurred in #: 
ERROR: prepared statement "a2" does not exist 

код рубин, который выполняется перед ошибкой

 
def self.get_ownership_record(id, key) 
    self.where("user_id=? AND key=?", id, key).first 
end 

pgbouncer конфигурации

 
; ######################################################### 
; ############# SECTION HEADER [DATABASES] ################ 
; ######################################################### 

[databases] 

fakedatabase=fake 

[pgbouncer] 

; ----- Generic Settings -------------------------- 
; ------------------------------------------------- 
logfile=/opt/local/var/log/pgbouncer/pgbouncer.log 
pidfile=/opt/local/var/run/pgbouncer/pgbouncer.pid 
listen_addr=* 
listen_port=5444 

; unix_socket_dir=/tmp 
user=_webuser 
auth_file=/Users/Shared/data/global/pg_auth 
auth_type=trust 
pool_mode=transaction 
; max_client_conn=100 
; default_pool_size=20 
; reserve_pool_size=0 
; reserve_pool_timeout=5 
; server_round_robin=0 

; ----- Log Settings ------------------------------ 
; ------------------------------------------------- 
; syslog=0 
; syslog_ident=pgbouncer 
; syslog_facility=daemon 
; log_connections=1 
; log_disconnections=1 
; log_pooler_errors=1 

; ----- Console Access Control -------------------- 
; ------------------------------------------------- 
admin_users=admin,nagios 
; ------------------------------------------------- 
; server_reset_query=DISCARD ALL; 
server_check_delay=0 
server_check_query=SELECT 1; 
; server_lifetime=3600 
; server_idle_timeout=600 
; server_connect_timeout=600 
; server_login_retry=15 

Это мое единственное решение, чтобы отключить подготовленные заявления?

database.yml

 
production: 
    adapter: postgresql 
    database: fakedatabase 
    username: admin 
    host: localhost 
    port: 5444 
    reconnect: true 
    prepared_statements: false 

EDIT

Я обновил pgbouncer.ini использовать сессии пулинговой

pool_mode=session

и раскомментировать

server_reset_query=DISCARD ALL;

и я до сих пор, казалось бы, случайно получать ошибки с подготовленными заявлениями, но на этот раз

 
An ActiveRecord::StatementInvalid occurred in #: 

PG::Error: ERROR: bind message supplies 2 parameters, but prepared statement "a1" requires 0 

Я поворачивал на протоколирования уровня заявления в моих журналах PostGreSQL и доложу более подробно, если это возможно.

+0

Я имел эту проблему под рельсы консоли. Решение было простым, мне нужно перезапустить консоль;) – MC2DX

ответ

2

советник Ричард Хукстон, после некоторых проб и ошибок.

мой окончательный установка выглядит как

database.yml

пришлось установить prepared_statements в true

 
production: 
    adapter: postgresql 
    database: fakedatabase 
    username: admin 
    host: localhost 
    port: 5444 
    reconnect: true 
    prepared_statements: true 

pgbouncer.ini

пришлось раскомментировать server_reset_query=DISCARD ALL;

и установить pool_mode=session

 
; ######################################################### 
; ############# SECTION HEADER [DATABASES] ################ 
; ######################################################### 

[databases] 

fakedatabase=fake 

[pgbouncer] 

; ----- Generic Settings -------------------------- 
; ------------------------------------------------- 
logfile=/opt/local/var/log/pgbouncer/pgbouncer.log 
pidfile=/opt/local/var/run/pgbouncer/pgbouncer.pid 
listen_addr=* 
listen_port=5444 

; unix_socket_dir=/tmp 
user=_webuser 
auth_file=/Users/Shared/data/global/pg_auth 
auth_type=trust 
pool_mode=session 
; max_client_conn=100 
; default_pool_size=20 
; reserve_pool_size=0 
; reserve_pool_timeout=5 
; server_round_robin=0 

; ----- Log Settings ------------------------------ 
; ------------------------------------------------- 
; syslog=0 
; syslog_ident=pgbouncer 
; syslog_facility=daemon 
; log_connections=1 
; log_disconnections=1 
; log_pooler_errors=1 

; ----- Console Access Control -------------------- 
; ------------------------------------------------- 
admin_users=admin,nagios 
; ------------------------------------------------- 
server_reset_query=DISCARD ALL; 
server_check_delay=0 
server_check_query=SELECT 1; 
; server_lifetime=3600 
; server_idle_timeout=600 
; server_connect_timeout=600 
; server_login_retry=15 

в основном позволяют подготовленные заявления в режиме сеанса пула с запросом сброса сервера по умолчанию.

1

Возможно, reading the FAQ поможет? Если у вас нет веских оснований не делать этого, сеансовое объединение должно быть разумным.

+0

Ссылка сейчас мертва – Stewart

+0

Спасибо Stewart - обновлено. –

+0

Я бы никогда этого не нашел! – Stewart

0

Вы можете использовать транзакции пулы, при условии, что вы PREPARE и EXECUTE подготовленный запрос внутри той же самой транзакции (чтобы избежать pgBouncer запуска server_reset_query между ними).

0

В моем случае доступ к каталогу postgres и запуск «DEALLOCATE ALL» разрешает проблему.

Если вы используете Heroku, как этот

> heroku pg:psql -a app_name 
app_name::DATABASE=> DEALLOCATE ALL 

 Смежные вопросы

  • Нет связанных вопросов^_^