ClickHouse / ClickHouse/clickhouse-go
Connection pool leak after load and pause in 2.42>=
- Dominant language
- Go
- Stars
- 3.3k
- Forks
- 680
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 14
Description
## Observed
1. We have load 66rps, on each request we do 6 parallel request in clickhouse with errGroup
2. MaxOpenConnections 100
3. We do rows.close() and check rows.Err()
4. We run monitoring db.Stats and log openConnections
5. We simulate load locally and add breakpoints on call rows.Scan() for 10 seconds
7. With driver version 2.42>=, we see big burst of open connections to 100 after pause and these connections don't close. You can try to add more pause to simulate this
8. With driver version 2.42<, we don't see big burst of open connections after pause and these connections close without any problems
## Error log
I don't have error log, because one of our pod in k8s have problem after 1 hour with connection pool, connection pool increased to 100 and doesn't closed connections
I tried to add reproducer without NDA or maybe you've already known where can be a problem
## Details
### Environment
* [ ] `clickhouse-go` version: 2.42>=
* [ ] Interface: ClickHouse API / `database/sql` compatible driver
* [ ] Go version: 1.25
* [ ] Operating system: ubuntu 24.0
* [ ] ClickHouse version: 25.8.13.73
* [ ] Is it a ClickHouse Cloud?
* [ ] ClickHouse Server non-default settings, if any:
* [ ] `CREATE TABLE` statements for tables involved:
* [ ] Sample data for all these tables, use [clickhouse-obfuscator](https://github.com/ClickHouse/ClickHouse/blob/master/programs/obfuscator/Obfuscator.cpp#L42-L80) if necessary
Contributor guide
Research direction
Start by reproducing the workload described with database/sql, six parallel ClickHouse requests, a 10-second pause around rows.Scan(), and db.Stats monitoring. Compare clickhouse-go 2.42+ with a pre-2.42 version, checking rows.Close(), rows.Err(), and whether open connections return to normal; done means the behavior is reproducible and the connection pool no longer remains full.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, sql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100