PG::Connection.async_exec returning nil instead of PG::Result

[Christos Zisopoulos]

Hello,

I am trying to trace an error I am seeing in a high volume Rails app. We have postgres behind pgbouncer being attacked by both a Rails app and some Sidekiq workers.

I am seeing an error where the following Rails code returns nil instead of a PG::Result:

https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb#L595

I should mention that we have disabled prepared statements as it is a requirement for pgbouncer to work.

Diging deeper into the pg gem's source I see that the documentation suggests that any calls to async_exec should always return a PG::Result, but my basic undestanding of this C function's code is that it could in theory return nil (Qnil)

https://bitbucket.org/ged/ruby-pg/src/b8debfea4331991b844dd656a60926bacc12a16c/ext/pg_connection.c?at=default#cl-3157

Am I correct? And is it a bug or a documentation problem?

[Lars Kanis]

Am 18.11.2014 um 17:10 schrieb Christos Zisopoulos:
> Diging deeper into the pg gem's source I see that the documentation
> suggests that any calls to async_exec should always return a
> PG::Result, but my basic undestanding of this C function's code is
> that it could in theory return nil (Qnil)
>
> https://bitbucket.org/ged/ruby-pg/src/b8debfea4331991b844dd656a60926bacc12a16c/ext/pg_connection.c?at=default#cl-3157
>
> Am I correct? And is it a bug or a documentation problem?

It's a bug. conn.async_exec should not return nil. Internally it calles
#block and #get_result. #block waits until some result data is available
and therefore #is_busy returns false. Then the result is retrieved with
#get_result. This is the contract with libpq. Obviously there is
something that breaks this contract.

I can trigger a nil result when calling get_result and async_exec from
two threads (attached). This also results in a lot of other unusual
errors, because one connection should be used by one thread only. The
activerecord connection pool usually does not issue one connection to
two threads, but this case could happen, if connections are checked out
manually from the pool.

Beside this, I can only think of pgbouncer as the error source.
Unfortunately I don't have any experience with this tool.

--
Kind regards,
Lars