I’m having issues when I deploy where the previous deployment isn’t releasing it’s database connections even though the instance doesn’t exist anymore.
I have a staging site, it had 20 connections to the primary and 20 to the replica + 1 for the flypgadmin user = 41 connections. After updating the env var to drop the pool size to 5 for the primary and replica I ended up with 52 connections.
After connecting to pg and terminating the connects I’m back to the expected 11 connections. I flyctl apps restart and now I’m at 22. When I update the env var and set the pool sizes to 10 I’m now at 42 connections.
I am experimenting with the staging site but this is happening on production too…
I’m also sent an email but the the forum seems to get faster responses.
It seems that you are restarting or redeploying the apps only and Postgres knows nothing about that.
From my understanding, Postgres doesn’t drop idle connections. So, whenever your app starts, new connections are added to the pool and the old ones remain idle.
So I don’t think that fly ctl is actively disconnecting your app. And I don’t know if you can your app disconnect on exit.
I am not sure if this is the right approach, but If you use the command below after you restart the app, it will restart each instance of Postgres from the cluster, one by one, to minimize downtime.
Hey @dsaravel - this app has been running for 6+ months no problems until this afternoon (the app probably gets 5 code deploys a day 5 days a week during the work week). The change also happened without code being deployed - just changing env vars.
I managed to get onto support and they’re looking into it.