Describe the bug
Per-database collectors
- postgres/tables
- postgres/indexes
- postgres/functions
- postgres/schemas
- postgres/custom
use defer conn.Close() inside the database loop, so all connections stay open until the entire Update() function returns. With N matching databases this results in N+1 simultaneous connections held open at once. For postgres/custom it is worse — connections are opened per database per subsystem, resulting in 1 + N × M simultaneous connections.
The fix is to replace defer conn.Close() inside the loop with an explicit conn.Close() immediately after use.
Expected behavior
Each per-database connection should be closed immediately after the collector finishes querying that database, keeping at most 1 connection open at a time during the loop.
P.S. Just in case: I understand that this issue is expected to be resolved in version 1.0, but it is still unclear when that version will be released. It would be great to have a v0.15.3 release with all the necessary fixes so we don’t have to wait for 1.0.
Thank you in advance.
Describe the bug
Per-database collectors
use
defer conn.Close()inside the database loop, so all connections stay open until the entire Update() function returns. With N matching databases this results in N+1 simultaneous connections held open at once. For postgres/custom it is worse — connections are opened per database per subsystem, resulting in 1 + N × M simultaneous connections.The fix is to replace defer conn.Close() inside the loop with an explicit conn.Close() immediately after use.
Expected behavior
Each per-database connection should be closed immediately after the collector finishes querying that database, keeping at most 1 connection open at a time during the loop.
P.S. Just in case: I understand that this issue is expected to be resolved in version 1.0, but it is still unclear when that version will be released. It would be great to have a v0.15.3 release with all the necessary fixes so we don’t have to wait for 1.0.
Thank you in advance.