Celery/Django app failure connecting to Postgres over private network
Project ID: f8880a56-7cb0-4ceb-891a-48baf9c79599
Hi, I've been trying for a good amount of time now to connect my django/celery app to postgres over the private url instead of the public one, but I always seem to land on the same error.
Have already read through many of the threads here on the help section and tried things like the sleep but did not help.
I am also not on an alpine based image, I am using
python:3.11-slim which is based on debian.
I am however able to connect to redis via the private URL with no issue.
On the screenshots you can see that I am sleeping for 3 seconds (tried even with 10 seconds and got nothing)
You can also see that redis connects correctly and I do receive one of the scheduled tasks.
And then you can finally see one of these tasks failing out due to an operational error, with "port 5432 failed: server closed the connection unexpectedly."
Any assistance I can get with this?
17 Replies
Project ID:
f8880a56-7cb0-4ceb-891a-48baf9c79599Project ID: f8880a56-7cb0-4ceb-891a-48baf9c79599
I am however able to connect to redis via the private URL with no issue.maybe a silly question, but can you also connect to postgres over the public network?
Yes, and that is how everything is working right now.
I have fully switched redis over to private networking, but I had to keep postgres using the public one because if I switch to private it just fails with the error from one of the screenshots above.
if the postgres client in use compatible with an ipv6 network?
That's honestly a good question.
I just use psycopg which is as far as I am aware, the only one, or at the very least the king of the hill of python postgres clients
In nearly 15 years of developing with python I've never used any other, or heard tbh.
and you're just using
DATABASE_PRIVATE_URL right?yeah
I just swap that DATABASE_URL to
DATABASE_PRIVATE_URL
is there anything unusual in the database logs?
Let me swap the variables and look at the postgres logs
restarted the postgres deployment, just to be sure, and the service is now redeploying after variable swap.
it is giving me some suspicious logs.
Im gonna try redeploying it
Interesting, after redeploying it (the postgres db, not the service), things seem to be working.
Im wondering if there was some issue with the first deploy post-migration. ( did just migrate this from a legacy db last night)
that's very odd, but glad it's working now!
yeah, I have no idea what happened here, but it just worked after redeploying the postgres db.
Could have been some weird artifact of the migration 🤷♂️
that's very possible