Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Stuck "Negotiating SSL", resulted in a large memory leak #123
Thanks for telling me about this.
Often when it gets stuck at this stage there's a firewall that prevents the connection.
However, that obviously shouldn't cause a memory leak. I'll have to look at the connection loop; I might have forgotten to free some data received from libpq. The connection loop uses more efficient polling in Postico, so it makes sense that the issue is worse in PG Commander.
Could you let me know which version/build of Postico and OS X you are using?
Does the memory usage drop to normal when you click cancel?
Build 1.0 (1243), OS X 10.10.5.
No, pressing cancel does not drop the memory usage, at least for the initial try. I just now got it up to 6.31GB while writing this comment. But, I then tried again, got it up to ~7GB, pressed cancel, and it went down to 6.31GB. I can't always reproduce the issue. It must be some specific sequence of events that causes it.
I found out that the hostname I was trying to connect to over SSH wasn't available to the SSH scope I was in (it was only available inside a docker container). Via command line, I could successfully SSH into the box, but if I tried to connect to the database using psql with the same credentials that I put into Postico, it wouldn't connect.
Hope that makes sense? There isn't any firewall in place - though the same sort of principle applies that the Posgres host it tries to connect to isn't resolvable. Probably something that can be done about that.
Okay, so I found out that the status "Negotiating SSL..." is a bit inaccurate. This is the first status that the PostgreSQL client library libpq reports after opening the connection. What Postico really does is wait for the SSH server to open the connection to the PostgreSQL server.
Anyway, I've been looking through the connection loop and I couldn't find anything the allocates memory while waiting for the connection. I also tried reproducing your issue by connecting to an SSH server and then connecting to a non-existing address like "test.local". However, Postico did not consume any memory in my testing.
Anyway, if a host is not resolvable, usually the SSH server should return an error after a short time. Because of the hang I assumed that a firewall was involved -- they are often configured in a way to silently swallow packets. It seems that Docker does something similar, but since I have no experience with Docker I really don't know what is going on.
I'll try some other things to reproduce your issue, but for now I really don't know how to find out where that memory leak is coming from. (Unless you happen to know your way around Instruments and the allocation tool...)
Thanks for the trace, @ddwyer!
I was able to find a typo in my code that caused Postico to check for new data from the server in a hot loop (rather than sleeping until data is available). This might also be the reason for the memory problem reported by @sman591 -- I didn't see that typo last time I looked through the code.
Here's a new build that should fix this issue:
Anyway, now Postico should use very little CPU while waiting for data from the SSH server. However, that probably won't help you -- Postico will probably still get stuck at the "Negotiating SSL..." phase.
Here's what's happening according to the sample you sent me: Postico has successfully connected to the SSH server, and it now asked the server to open a channel to the PostgreSQL server. Now it's waiting for a response from the SSH server. Common reasons for getting stuck at this phase are Firewalls or internet filters that possible that the SSH server can't connect to the PostgreSQL server because of a Firewall or an internet filter of some kind.