Connecting to postgres through proxy

I have an app deployed on Fly and its able to connect to a Fly Postgres DB.

From my laptop, I can run

fly proxy 5555:5432 -a foody-v2-db

and then connect via psql using a a URI like so:

psql postgres://foody_v2:xxxxxxx@localhost:5555/foody_v2
psql (14.11 (Homebrew), server 15.6 (Debian 15.6-1.pgdg120+2))
WARNING: psql major version 14, server major version 15.
         Some psql features might not work.
Type "help" for help.

foody_v2=#
\q

If I try to connect through my application (Rust, using loco.rs) locally, using the same URI in DATABASE_URL I get timeout errors:

 DATABASE_URL='postgres://foody_v2:xxxxxx@localhost:5555/foody_v2' cargo run -- task -e production create_user name:Foo email:some@example.com password:abc123
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/foody-cli task -e production create_user 'name:Foo' 'email:some@example.com' 'password:abc123'`
2024-04-16T21:07:11.867024Z  INFO app: loco_rs::config: loading environment from selected_path="config/production.yaml" environment=production
Error: Connection Error: pool timed out while waiting for an open connection

Caused by:
   0: pool timed out while waiting for an open connection
   1: pool timed out while waiting for an open connection

pgcli originally also refused using the URL, but I was able to decompose it into individual parameters and then it works?

The password I’ve been using is from `$OPERATOR_PASSWORD.

Hi… I’m surprised by this, since that’s usually the postgres user’s password, and instead you’re logging in as foody_v2.

Are you sure that’s what you had as the xxxxxxx during the initial, successful psql attempt?

I did an experiment and deleted the old db app, created a new one, attached it copy-pasted the creds and am able to use psql with the postgres + $OPERATOR as well as the printed credentials from DATABASE_URL.
Same with pgcli. Its just my Rust app using sqlx that does nor want to work with the proxy. The same app in fly itself seems to connect just fine and migrate the database forward!

Turns out I had to set an acquire_timeout in my local application. I guess takes fractionally longer than going through the proxy than going through the internal network.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.