Postgres Disabling Prepared Statements Breaks with Replication

[ahueniken]

If your database.yml sets prepared_statements to be false (in my case we need to to use pgbouncer)

default: &default
    adapter: postgresql
    prepared_statements: false
    pool: 5
    timeout: 5000

You'll get the following error

PG::ProtocolViolation: ERROR:  bind message supplies 1 parameters, 
but prepared statement "a1" requires 0
: SELECT  "people".* FROM "people" WHERE "people"."id" = 1 LIMIT 1

For a simple call like @person = Person.find(params[:id])
In shards.yml I have fully_replicated: true

Enabling prepared statements again fixes the issue.

What's odd however is that on Heroku with pgbouncer in place, it appears to be working with prepared_statements: false, just on my local machine it breaks.

Has anyone experimented with prepared statements and octopus?

[roodion]

Hello @ahueniken,
if you still expecting this issue, probably you just missed prepared_statements: false for all slaves you have in config/shard.yml ?

to be 100% sure you doing right, you can monkey-patch AR initialazing and print configuration. then you can notice that configuration reloads on each new slave connection. that's why you have to disable prepated statements for each slave manually.

initializers/database_initializer.rb
class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter                                           

alias initialize_super initialize                                       
  def initialize(connection, logger, connection_parameters, config)                                 
    p "config: #{config.inspect}"
    config = config.merge(prepared_statements: false)                             
    p "config_patched: #{config.inspect}"                  
    initialize_super(connection, logger, connection_parameters, config)   
  end                                                                                               
end     

[churro-s]

@ChauskinRodion your comment pointed me in the correct direction, thank you. In my case, I was experiencing this issue because the prepared_statements setting was mismatching between my master database and shard config. Setting both to false fixed my issue.