I was breaking my head for a long time over this. I previously had a working function (not in app platform) that was connecting to an app platform development postgres database, all correct with the self-signed certificate and all. At some point it stopped working, I think when I promoted the dev db to a full managed database.
How I (somewhat) got it working again was by not using the (public) hostname of the database, but it’s IP address… I figured this out because I didn’t get errors from the TLS handshake, even when providing wrong ca certificate, so I figured it must be a lower level connectivity issue. So I did a DNS lookup inside the function, and noticed an IP address in range 10.x for the hostname, so private range. When I substitute the public IP address I get from a host lookup externally I get something in the 164.x range, so public range, and when I put this in the connection string it all starts working again.
The database has no trusted sources specified, i.e. it is accessible on the public IP. I did specify trusted sources at some point, maybe that caused a change in internal DNS servers?
So why is this, and how can I resolve it?
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Click below to sign up and get $200 of credit to try our products over 60 days!
Thanks for posting about this issue. What you describe sounds like something isn’t working correctly. We’d like to help investigate it. The best way to do that is via our support ticket system. Please open a ticket using https://cloudsupport.digitalocean.com/s/. In the ticket, include information you think is relevant, like which function in which namespace, which database cluster, etc.