(Postgrex.Error) ssl not available

Where you say it “clearly works” in the screenshot, that’s not really true: your application starts, but the Postgrex processes log some errors. The application can run even if the Postgrex processes are down, which is normal if you’re following a sort of standard setup, with your Ecto.Repo as a child of the application supervision tree.

As for the SSL, it’s hard to debug this without seeing any of the configuration you’re using. What address are you using to connect to Postgres?

As one of the replies on that issue calls out, the message isn’t related to the Elixir SSL machinery: it’s caused by the Postgres server replying N to an SSLRequest message. The Postgrex implementation:

https://github.com/elixir-ecto/postgrex/blob/d888ae474cfcf2ac2a4cb353af45df65cdb8b7e5/lib/postgrex/protocol.ex#L722-L743

I would expect that setting ssl: false in the configuration would avoid this, though.

Address: postgres://postgres:postgres@localhost:5432/my_app_dev

As far as config, there’s a lot of application-specific config, but here is the repo config:

config :my_app, MyApp.Repo,
  username: "postgres",
  password: "postgres",
  database: "my_app_dev",
  hostname: "localhost",
  show_sensitive_data_on_connection_error: true,
  pool_size: 10

The reason I say the app “clearly works” (which I realize I didn’t mention) is because mix ecto.setup/mix ecto.reset works. Migrations run just fine, my seeds.exs successfully seeds data (I can see the seed data in the database tables themselves). Most of the tests (many of which use the database) also pass. Some tests do fail though, with:

  5) test things should work (MyApp.Resolvers.ThingResolverTest)
     test/my_app_web/resolvers/thing_resolver_test.exs:110
     ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 11266ms. 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
     
     stacktrace:
       (db_connection 2.4.2) lib/db_connection/ownership.ex:96: DBConnection.Ownership.ownership_checkout/2
       (ecto_sql 3.9.0) lib/ecto/adapters/sql/sandbox.ex:500: Ecto.Adapters.SQL.Sandbox.checkout/2
       (my_app 0.1.0) test/support/data_case.ex:33: MyApp.DataCase.__ex_unit_setup_0/1
       (my_app 0.1.0) test/support/data_case.ex:1: MyApp.DataCase.__ex_unit__/2
       test/my_app_web/api/resolvers/thing_resolver_test.exs:1: MyAppWeb.Resolvers.ThingResolverTest.__ex_unit__/2

But then after waiting a bit and running mix test --failed, those same tests pass.

Turns out I misunderstood some of the application I’m working on!

It has a config for an AWS Redshift repo, but it was supposedly disabled when running locally. Despite that, the application.ex file will still try to start up the Redshift connection regardless of the value in the config file.

So now I’ve added a helper in the application children list like so:

# An application children helper function
defp common_backend_children(mode) do
  [
    # ...
    maybe_enable_redshift(),
    # ...
  ]
  |> Enum.reject(&is_nil/1)
end

defp maybe_enable_redshift() do
  # cfg!/1 is a configuration helper that reads a YAML file for extra config
  if cfg!([:redshift, :enabled]) do
    MyApp.RedshiftRepo
  else
    nil
  end
end

Sooooooo disregard this entire thread. Thanks for all of the help!