pg instrumentation doesn't work with Promise based API

[wmonk]

The title says it all really, the instrumentation added to Client.prototype.query for the pg does not handle the Promise based API that is exposed. Happy to open a PR for this if wanted.

A feature for this that I noticed in our own sub-optimal usage of the library would be to instrument the part of the code that waits for a connection from db server / connection pool. We are using lambda without the AWS connection pool offering, so just grab a fresh connection each time. So when you look at the trace in Honeycomb UI, it has whitespace at the point where (I'm guessing) it's waiting for a connection. I would guess that if your db server / connection pool is exhausted, it would cause some amount of latency that would not be covered in your trace -- I might be wrong here though.

[joerayme]

I think we might be encountering the same problem—some of our queries do seem to be appearing in the traces (mostly transaction queries i.e. BEGIN and ROLLBACK/COMMIT), but the actual query within the transaction often doesn't appear (although it's not consistent—some of them do seem to and I can't figure out what's different between them).

I've narrowed my particular problem down to this line in pg.js—when the query isn't traced, this is what seems to be happening. From my understanding of what's going on in traceActive() this seems to match up with the original report that it's something to do with the async nature of the API.

Is there a workaround/fix for this?

[joerayme]

Just in case anyone else is having the same problem, I've found that it's probably related to this bug and is fixed in Node 14.5.0—I've verified that updating to that version does seem to fix the problem, at least in my repro app. Now to upgrade our APIs...

[vreynolds]

Hello,

We will be closing this issue as it is a low priority for us. It is unlikely that we'll ever get to it, and so we'd like to set expectations accordingly.

As we enter 2022 Q1, we are trimming our OSS backlog. This is so that we can focus better on areas that are more aligned with the OpenTelemetry-focused direction of telemetry ingest for Honeycomb.

If this issue is important to you, please feel free to ping here and we can discuss/re-open.