-
Notifications
You must be signed in to change notification settings - Fork 440
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.
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
contrib/jackc/pgx: add initial support #1537
Conversation
dc04df1
to
df5a4e2
Compare
this is merely the first step, before I add tests and implement other tracer interface, I want to gather some feedback on the API as well as the data being traced |
one more question is, this requires pgx v5+ which requires go 1.18+, is this ok, or do we need to wait for go 1.20 as the lib still supports 1.17? |
df5a4e2
to
b300a57
Compare
If it doesn't build / work at all with Go 1.17 then unfortunately this will need to wait until we remove support for Go 1.17 with the release of Go 1.20. |
b300a57
to
91ed48b
Compare
I see, as generics is used, I suppose this will have to wait... but do you mind taking a look at the API or the data collected? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks like a step in a good direction for supporting pgx
v5 directly. I've left a couple comments here and there.
I wonder if there's a way to reduce the duplication introduced between this and the contrib/database/sql package, I'm not sure there's a clean way to do it, but it would make future changes to SQL support easier/less brittle.
contrib/jackc/pgx/pgx.go
Outdated
) | ||
|
||
// TracedConn returns a traced *pgx.Conn | ||
// note that connect trace are not effective this way |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what's meant by this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see https://github.com/jackc/pgx/blob/987de3874e0fc18b8c468d27cb9de9b2cd67540c/conn.go#L106. basically, the connection string used in Connect
simply can't specify the tracer. the connection has been established before adding the tracer, hence the "Connect" span wouldn't be added in this way. I hesitated when providing this, but decided to include it to provide "compatibility"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, I've corrected the implementation, now it parses the conn string and update the tracer so the comment is obsolete and removed. FYI
contrib/jackc/pgx/trace.go
Outdated
} | ||
|
||
// TraceQueryStart marks the start of a query, implementing pgx.QueryTracer | ||
func (t *tracer) TraceQueryStart(ctx context.Context, _ *pgx.Conn, data pgx.TraceQueryStartData) context.Context { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add unit and integration tests for these? (See contrib/database/sql for example tests)
Also I think a short example file showing how it's expected to be used would be very helpful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do them all once I have some feedback from more experienced user of pgx, thanks!
contrib/jackc/pgx/trace.go
Outdated
} | ||
|
||
if t.traceStatus { | ||
span.SetTag("pq.status", data.CommandTag.String()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be pgx.status
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, I meant that "this is a status from postgresql", rather than specifically from pgx, what do you think?
contrib/jackc/pgx/trace.go
Outdated
|
||
// tracer contains configs to tracing and would implement QueryTracer, BatchTracer, | ||
// CopyFromTracer, PrepareTracer and ConnectTracer from pgx. | ||
type tracer struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a better name here might be config
to align with how the contrib/database/sql package works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought of that, but the pgx interface works a bit differently 🤔 it exposes a series of interfaces and calls them in the queries/connections etc. I suppose it's a bit odd to make a config
satisfy a QueryTracer
/BatchTracer
etc?
contrib/jackc/pgx/pgx.go
Outdated
} | ||
|
||
// TracedPool returns a traced *pgxpool.Pool for concurrent use | ||
// note that connect traces are not effective this way |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is meant by "connect traces are not effective" As in the connect
span doesn't work for pooled connections?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar to the above, see https://github.com/jackc/pgx/blob/987de3874e0fc18b8c468d27cb9de9b2cd67540c/pgxpool/pool.go#L159, basically with connection strings, tracers can't be specified and hence the "connect" trace can't be collected this way
thank you for the comments! let me address them all, in the mean time, I'd like to explain that pgx basically provides a different and more performant interface, other than database/sql. using database/sql would defeat the purpose and in fact rather unnecessary (as github.com/jackc/pgx/v5/stdlib can directly be used). feel free to continue discussing this! |
allow me to elaborate a bit more about pgx vs database/sql. see https://pkg.go.dev/github.com/jackc/pgx/v5/stdlib#pkg-overview, you could use pgx with that interface, but see https://pkg.go.dev/github.com/jackc/pgx/v5#pkg-overview,
in other words, it provides features and performance that couldn't be utilized if you use database/sql interface through it, hence this is necessary. |
converting to draft since we can only talk about it when go 1.20 comes out |
Go 1.20 is now out and is compatible with dd-trace-go, so should this PR be moved out of draft at this time? |
thanks for reminding, I'll make time for this! |
Hey @mrkagelui tell me if you need help with pushing this PR forward |
hey thanks for reminding @doron-cohen , been sick last week and work and life have been both crazy, I think I'd have some bandwidth next month. anyone feel free to take over. |
@mrkagelui thank you for your work on this! I would like to help, I've prepared a PR that includes the content from this one over at #1840. So far it only includes a merge from main and is moved out of the draft state so that upstream CI tests can run. I'm happy to hand back over to you at any point if you get time. |
thank you so much @statik ! unfortunately I would only have time in the next month. please kindly carry on if you can. I'll contribute there if needed. |
contrib/jackc/pgx/pgx.go
Outdated
for _, opt := range options { | ||
opt(t) | ||
} | ||
p.Config().ConnConfig.Tracer = t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During our implementation of dd-tracer-go and pgx, we had to do something like:
config := p.Config()
config.ConnConfig.Tracer = t
poolWithTracer, err := pgxpool.NewWithConfig(ctx, config)
Pretty new to Go so I can't tell you exactly why, but the pointer reference from p.Config() was different than p, so editing that config didn't affect the original pool, so recreating the pool with the updated config was necessary to get things working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for pointing this out, I think it has to do with the fact that the conn configs can't really be modified on the fly (for concurrency reasons). I'll use this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you are still interested @xzile , kindly see my updated implementation, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Looks good.
@mrkagelui PR #1840 has been closed. Would you be open to moving this one out of the |
This is really great and looks like it's really close! I'm an eager adopter as well and would really appreciate it if anyone has a rough idea of when it can be expected to make it in just so we can set the right expectations and avoid over-investing in other workarounds. Much thanks all around! |
This looks great! Are there any plans to move this along into a review state? @mrkagelui |
Hey sorry everyone who's watching, I recently could finally find some time to work on this. let me know if anyone else could help (to review etc). I'll see if it's already done first. |
cfb902e
to
b070e84
Compare
update: I've implemented all tracer interfaces in pgx, will add tests later. I'd appreciate it if anyone can help to see if the data points in the implementation is sufficient, or if the logic looks right. |
bbac71d
to
6bb79bb
Compare
@ajgajg1134 what has to happen next for this to get into the library? We want to migrate from pq which is unmaintained but DB query tracing is very important to us. We are considering to move to the OTEL client just to allow it but I see this PR is in final steps, no? |
We acknowledge the significant amount of people that want to see this PR through and we'll be taking a closer look soon before trying to finalize it |
Closing this PR in favour of #2410. |
fixes #697