How to handle connection lost in Go?
I researched some of the currently popular sql packages and found that almost none of them have a feature that throws an error immediately when a connection is lost. For example, in nodejs with MySQL, we can listen for errors using connection.on('error').
However, in Golang (at least in several popular packages), there isn’t a similar feature available. Upon further investigation, it’s not hard to understand why.
The sql package creates and frees connections automatically; it also maintains a free pool of idle connections. If the database has a concept of per-connection state, such state can be reliably observed within a transaction (Tx) or connection (Conn). Once DB.Begin is called, the returned Tx is bound to a single connection. Once Commit or Rollback is called on the transaction, that transaction’s connection is returned to DB’s idle connection pool. The pool size can be controlled with SetMaxIdleConns.
In simple terms, when you call sql.Open, it does not actually establish a connection; instead, it maintains a connection pool internally and only attempts to connect when necessary. This means that if you lose a connection due to network issues while executing a query, database/sql will attempt to retry for you at the lower level.
On the bright side, this is a good thing, as it saves you from having to handle the retry logic yourself. However, sometimes you might prefer to be aware of a lost connection before executing a query, so that the entire application knows about the issue in advance.
If you want to achieve similar functionality, you will need to rewrite the underlying Dialer logic to ensure that your application is notified immediately when a network disconnection occurs.
Related Posts
- When Measurement Becomes the Goal: From Window Tax to PR Counts I once wrote a small tool to count how many PRs I had contributed in a quarter, how many reviews I had left, and how many tickets I had closed, hoping to use the numbers to prove my output to my manager. My manager simply said performance is not judged by output alone. Only years later did I understand—when measurement becomes the goal, it is no longer a good measure. From Britain’s window tax and the Hanoi rat bounty to evaluating developers by PR count today, the mechanism is exactly the same.
- Using Cloudflare Images for Image Storage and Transformation Putting an image on a web page is the easiest thing in frontend. But doing it properly — resizing, generating every format, holding up under traffic — turns into a whole solution of its own. I ended up handing all of it to Cloudflare Images and keeping just one original.
- Stop Using Access Keys Already Access Keys are an easily overlooked security risk on AWS. Use OIDC with IAM Roles so GitHub Actions can securely access AWS resources without any secrets.
- Database Primary Keys: AUTO_INCREMENT, UUID, and UUIDv7 Backend developers often have to decide on a primary key: auto increment or UUID? What about collisions? How much faster is UUIDv7 compared with created_at + index? After benchmarking 20 million rows and looking at the design trade-offs, this post gives you the answer.