fix #141

[goldwind-ting]

Is it reasonable to check the connection in build? @djc

[djc]

This seems more like a workaround than a fix for the issue described in #141 -- AFAICT in this case the connection would still time out, but it would happen at pool instantiation time rather than at pool.get() time?

[goldwind-ting]

This seems more like a workaround than a fix for the issue described in #141 -- AFAICT in this case the connection would still time out, but it would happen at pool instantiation time rather than at pool.get() time?

Yes, it would still time out, but I think in this case it is caused possibly by network.
If merged the PR, it will return directly when failed to check configure, e.g. password, database name.
And if you think this is not reasonable, I will try another solution.

[djc]

Yes, I don't think this is a good solution. I'd like to understand why we're timing out in that case instead of immediately-ish getting an error about the password being wrong.

[goldwind-ting]

Yes, I don't think this is a good solution. I'd like to understand why we're timing out in that case instead of immediately-ish getting an error about the password being wrong.

Seem that when failed to connect database, it would loop until timeout and do not send guard to waiters channel.

[djc]

Right, so I think the correct fix would be to check the error returned by connect() in that case and avoid looping if we can determine the problem is likely to be permanent.