8000 Implement AcquireTracer and ReleaseTracer for TraceLog by stampy88 · Pull Request #2313 · jackc/pgx · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Implement AcquireTracer and ReleaseTracer for TraceLog #2313

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
May 10, 2025
Merged

Implement AcquireTracer and ReleaseTracer for TraceLog #2313

merged 2 commits into from
May 10, 2025

Conversation

stampy88
Copy link
Contributor
@stampy88 stampy88 commented May 8, 2025
  • TraceLog now implements the pgxpool.AcquireTracer and pgxpool.ReleaseTracer interfaces to log connection pool interactions.

@stampy88
Implement AcquireTracer and ReleaseTracer for TraceLog
baca2d8 
- `TraceLog` now implements the `pgxpool.AcquireTracer` and `pgxpool.ReleaseTracer` interfaces to log connection pool interactions.
@jackc
Copy link
Owner
jackc commented May 10, 2025

The code seems fine.

But this change could have a side effect of greatly 8000 increasing the amount of log output. If someone is mostly using Query, QueryRow, and Exec directly against a pool then the amount of output on the info level would triple. Instead of getting a single log entry for the query, they would get acquire, query, and release log entries.

I'm not sure this is a desirable outcome.

@stampy88
Copy link
Contributor Author

well, I think the additional logging would be useful if you don't have other visibility into your app. Knowing how long it took to acquire a connection is definitely helpful. Also, these log statements are pretty light; they are not like the prepare, query, or even connect in that it is really just timing/error information versus outputting SQL statements and args. One option would be to set this at the debug level instead of info.

@jackc
Copy link
Owner
jackc commented May 10, 2025

Also, these log statements are pretty light; they are not like the prepare, query, or even connect in that it is really just timing/error information versus outputting SQL statements and args.

I'm just thinking about how the volume of messages could be greatly increased.

One option would be to set this at the debug level instead of info.

Let's do that.

@jackc jackc merged commit 777e7e5 into jackc:master May 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@stampy88 @jackc
0