-
Notifications
You must be signed in to change notification settings - Fork 867
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom dial func causes pgx to hang indefinitely #1413
Comments
It is really messy working with non-blocking IO and timeouts and TLS. The ultimate solution would be non-blocking IO to be directly supported by net.Conn and tls.Conn (something like golang/go#15735 or golang/go#36973). I'm not happy with pgx's But that doesn't solve anything now.
Could this be wrapped with something that doesn't implement the // Tell the driver to use the Cloud SQL Go Connector to create connections
config.ConnConfig.DialFunc = func(ctx context.Context, _ string, instance string) (net.Conn, error) {
conn, err := d.Dial(ctx, "project:region:instance")
if err != nil {
return nil, err
}
return NetConnWrapperThatDoesNotImplementSyscallConn(conn), nil
}
This wouldn't be too bad. It's not supported on Windows so there already is an entire path with it disabled. It would just be a bit of plumbing to expose that setting. Or for that matter, the I know this doesn't help now, but I really think that the Go |
After thinking about this for a few days, I realize we can isolate the SyscallConn behavior to just MySQL and so don't need any changes here. Thanks for your hep. |
The Cloud SQL Go Connector works with pgx by providing an implementation of pgconn.DialFunc that creates a TLS 1.3 connection in a seamless way for callers.
The connector wraps the resulting TLS connection in part to support a MySQL health check by adding an implementation of
syscall.SyscallConn
. The full details are here, but in short, the MySQL driver usessyscall.SyscallConn
to do a zero byte read to ensure the connection is alive, and otherwise knows to recycle it. Even though the Go standard library advises that reading and writing to the underlying connection will corrupt the TLS session, this works because no reads or writes are actually performed.Meanwhile, in the pgx v5, there is now a new NetConn type that uses the
syscall.SyscallConn
interface to perform non-blocking reads and writes.When I try to upgrade the Go Connector to pgx v5, though, the reads and writes hang indefinitely, presumably because pgx is trying to use the
syscall.SyscallConn
interface which otherwise does not work given the connection is actually encrypted.The options for fixing this in the Go Connector seem to be:
None of the above are ideal. Are there any other options here?
The text was updated successfully, but these errors were encountered: