Maximum number of seconds to wait for a new connection from the pool, 0 means no timeoutĬonfigures whether to use TLS. Maximum number of seconds to wait for a new connection to be opened, 0 means no timeout My solution was to use a different port for the database (I was port-forwarding from remote to localhost).Name of the schema you want to use, e.g. Then go into TaskManager>Details to see if another process is using that port
Shutdown the database and use netstat in Powershell to see if something else is running on the port (in my case 8123 for Clickhouse) If the connection is refused then there might be another process running on that port. The parts that helped me find a solution (paraphrased) were: But it was not working from Datagrip running on Windows. It was working fine via JetBrains Gateway from a WSL P圜harm project. I could not connect to my database from Datagrip on Windows. Maybe some parts of Mostafa's solution could be added to the troubleshooting guide?
#Datagrip postgres gui windows#
Mostafa's solution helped me figure out why I could not connect to a database with Datagrip on Windows after I had already tried using the troubleshooting guide from here: Now, I should again stress, that for some reason, pgAdmin didn't ahve any problem with the port forwarding and could connect to the DB with no problem, which led me to believe the port and connection should be fine. Netsh interface portproxy delete v4tov4 listenport=5432 listenaddress=127.0.0.1 Netsh interface portproxy delete v4tov4 listenport=5432 listenaddress=0.0.0.0 So, a quick: netsh interface portproxy show all
A quick search led me to this answer:Īnd I also remembered that for a previous project on an older version of docker in WSL2 which had a lot of problems forwarding ports, I had used port forwarding on this port. Going into TaskManager>Details, finding PID 4846 led me to find out that "Windows IP Helper service" is listening on this port. I found out that a PID:4846 is running on 5432. Which showed me that even when the DB container is not running and even Docker itself is closed, something is listening on 5432. I inspected the ports using: netstat -an | findstr 5432 I still maintain that because pgAdmin could connect to that DB, DataGrip should have been able to do the same, but let's go down the rabbit hole shall we? After reading the log file myself, I noticed that it's a socket exception which led me to believe that there's something wrong with the port 5432. I also cannot establish this connection from within "Goland", which was the first thing I tried. Please bear in mind that DataGrip can easily connect to the two other containers in this docker-compose file.įor your info, this is my docker compose, which I use to run the three containers: version: "3.9" The peculiar thing about this is that pgAdmin can connect to the PostgreSQL on localhost:5432.
DataGrip can easily connect to the Clickhouse on localhost:8123, and also to the Mongo on localhost:27017 but for some reason it cannot connect to the PostgreSQL running on 5432.
One Mongo, One Clickhouse, and one PostgreSQL. I have Docker Desktop installed on windows 10. Hello everyone! I think the title says it all.
0 kommentar(er)
