fireproofsocks
DBConnection.ConnectionError for regular queries, but migrations work
This is on the tail of Problem Creating PostGres schema in Ecto migration... and BONUS problems with queries – sorry for a double-post (things have evolved a bit).
I’m trying to get Ecto up and running on a new server and new database, and it’s been a rough ride.
Oddly, running migrations works fine – the commands that are run (successfully) boil down to this:
iex> config = [
pool: DBConnection.ConnectionPool,
pool_size: 50,
database: "my_app",
name: :migrations
# ... etc...
]
{:ok, pid} = MyApp.Repo.PGRepo.start_link(config)
Ecto.Migrator.run(MyApp.Repo, :up, all: true, dynamic_repo: :migrations)
Process.exit(pid, :normal)
(Note: we use this command on prod because it’s a built release and we have to run migrations without mix)
But as soon as I try to actually run a normal query, everything fails:
iex> Ecto.Adapters.SQL.query!(MyApp.Repo, "SELECT VERSION()", [])
** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 1094ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
1. Ensuring your database is available and that you can connect to it
2. Tracking down slow queries and making sure they are running fast enough
3. Increasing the pool_size (although this increases resource consumption)
4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
See DBConnection.start_link/2 for more information
(ecto_sql 3.8.3) lib/ecto/adapters/sql.ex:932: Ecto.Adapters.SQL.raise_sql_call_error/1
This one has really been dogging me. I thought the configs etc. would copy over from a working app, but I’m missing something. Any help or suggestions are appreciated.
Most Liked
fireproofsocks
Postgres is great… until it isn’t. And tonight I was really missing the visibility that MySQL offered… even getting a dump from a PostGres instance or restoring it is a quite difficult by comparison. I’m discovering the caveats between pg_dump and pg_dumpall and getting quite frustrated that I keep having to drop into the psql shell to get good views on what’s going on… oiy.
fireproofsocks
Sounds like this hits close to home. Maybe you could publish your suite of tools and charge corporate rates to use them and then retire in infamy. Solidarity ![]()







