Skip to content

fix(instrumentation-pg): correct db.client.connection.count metric counting to handle multiple pg pools#3367

Draft
trentm wants to merge 2 commits intoopen-telemetry:mainfrom
trentm:trentm-pg-pool-metrics-fix-issue3354
Draft

fix(instrumentation-pg): correct db.client.connection.count metric counting to handle multiple pg pools#3367
trentm wants to merge 2 commits intoopen-telemetry:mainfrom
trentm:trentm-pg-pool-metrics-fix-issue3354

Conversation

@trentm
Copy link
Contributor

@trentm trentm commented Jan 29, 2026

Before this change the instrumentation was assuming there was only ever
one active PG pool.

Fixes: #3354

Checklist

  • Add tests
  • Discuss whether getPoolName and db.namespace could include the PG schema, if any. Though really this would be a separate PR.

…counting to handle multiple pg pools

Before this change the instrumentation was assuming there was only ever
one active PG pool.

Fixes: open-telemetry#3354
let connCount = connCountFromPoolName[poolName];
if (!connCount) {
connCount = {used: 0, idle: 0, pending: 0};
connCountFromPoolName[poolName] = connCount;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A concern here is that connCountFromPoolName will grow for every new PG poolName. Entries are never removed from this mapping.

In normal usage I would think an app would only ever have one or a few PG pools. If this is a concern, we could use something like an LRU cache (e.g. https://github.com/isaacs/node-lru-cache, or https://github.com/isaacs/ttlcache).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

@opentelemetry/instrumentation-pg: multiple pools cause db.client.connection.count to be recorded incorrectly

2 participants