separate write db and read db - #121
Open
sredxny wants to merge 13 commits into
Open
probelabs / Visor: performance
failed
Sep 30, 2025 in 5m 5s
🚨 Check Failed
performance check failed because fail_if condition was met.
Details
📊 Summary
- Total Issues: 3
- Critical Issues: 1
- Warning Issues: 1
🔍 Failure Condition Results
❌ Failed Conditions
- global_fail_if: Global failure condition met
⚠️ Severity: Error
🐛 Issues by Category
⚡ Performance (3)
- 🚨 persistent/internal/driver/postgres/lifecycle.go:195 - The
Close()function will cause a panic due to attempting to close the same database connection twice when no separate read replica is configured. In single-connection mode,l.readSQLDBandl.writeSQLDBpoint to the same instance. The logic incorrectly attempts to close the connection a second time, leading to apanic: close of closed channel. This is a critical resource management failure that can lead to a denial of service. ⚠️ persistent/internal/driver/postgres/schema.go:321 - TheDropTablefunction executes aSELECT COUNT(*)query on the read replica before dropping the table. On very large tables, this can be a slow and resource-intensive operation, potentially requiring a full table scan and impacting the performance of other read queries.- ℹ️ persistent/internal/driver/postgres/indexes.go:13 - The compilation of the regular expression for
sanitizeIdentifierhas been moved to a global variable. This is a positive micro-optimization that avoids the performance overhead of recompiling the regex on every function call.
Generated by Visor - AI-powered code review
Annotations
Check failure on line 217 in persistent/internal/driver/postgres/lifecycle.go
probelabs / Visor: performance
performance Issue
The `Close()` function will cause a panic due to attempting to close the same database connection twice when no separate read replica is configured. In single-connection mode, `l.readSQLDB` and `l.writeSQLDB` point to the same instance. The logic incorrectly attempts to close the connection a second time, leading to a `panic: close of closed channel`. This is a critical resource management failure that can lead to a denial of service.
Raw output
To prevent a panic from a double-close operation, determine if a single connection is being used *before* any close operations are performed. Store this state in a boolean and use it to conditionally close the read connection only if it's a separate instance.
Check warning on line 326 in persistent/internal/driver/postgres/schema.go
probelabs / Visor: performance
performance Issue
The `DropTable` function executes a `SELECT COUNT(*)` query on the read replica before dropping the table. On very large tables, this can be a slow and resource-intensive operation, potentially requiring a full table scan and impacting the performance of other read queries.
Raw output
Re-evaluate the necessity of returning an exact row count when dropping a table. If this is for informational purposes, consider if the feature is worth the potential performance cost. An alternative is to retrieve an estimated row count from PostgreSQL's statistics (`pg_class.reltuples`), which is much faster, though less accurate.
Check notice on line 13 in persistent/internal/driver/postgres/indexes.go
probelabs / Visor: performance
performance Issue
The compilation of the regular expression for `sanitizeIdentifier` has been moved to a global variable. This is a positive micro-optimization that avoids the performance overhead of recompiling the regex on every function call.
Raw output
This change is a good performance practice and should be maintained.
Loading