Skip to content
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

Should pg gem be only a dev dependency for pg auto-instrumentation? #86

Closed
bixu opened this issue Jul 9, 2022 · 7 comments
Closed

Should pg gem be only a dev dependency for pg auto-instrumentation? #86

bixu opened this issue Jul 9, 2022 · 7 comments
Labels
stale Marks an issue/PR stale

Comments

@bixu
Copy link

bixu commented Jul 9, 2022

I'm working with an old ruby app at $job that has pg version 0.21.0 -- I think this what causes the auto-instrumentation to fail...

spec.add_development_dependency 'pg', '>= 1.1.0'

@plantfansam
Copy link
Contributor

@bixu are you able to provide reproduction steps? You may want to use the bug issue template.

@ericmustin
Copy link
Contributor

The min compatible version for this instrumentation is, in fact, 1.1.0

What the reason for that min version is, i'm not totally sure. @ahayworth contributed this instrumentation, perhaps he could provide context on that min version?

@plantfansam
Copy link
Contributor

Ah, I was confused — no reproduction steps necessary. @ericmustin beat me to it — not sure why we are requiring 1.1.0. I guess we could generate an appraisal with the earlier gem version and see if specs are green?

@ahayworth
Copy link
Contributor

👋 Here's the original context:

The async_exec/sync_exec (and related family of) methods were added in this version, which is now 5 years old. In theory, if someone really wanted to, we could support earlier versions than this but ¯(ツ)/¯

I didn't see a reason to support anything older at that time. Notably, v1.1.0 wasn't actually 5 years old at the time I wrote that - but as of now it's about 4 years old. 😆


Supporting older versions is possible, but it's not as simple as just loosening the specs and seeing if it works. This instrumentation works by creating wrapper methods for stuff like async_exec, prepare, query, etc; starting a span; and then forwarding all args on to the real async_exec method (or prepare, query, whatever). If we simply loosened the requirement, we'd be creating wrapper methods for library methods that don't actually exist. We'd need to wrap different sets of methods depending on what version of the gem was running. Not trivial - but not impossible, either.


@bixu is it possible to upgrade pg to at least version 1.1.0? That would by far be the easiest thing to do. I would prefer not to complicate the instrumentation without really good reason.

@plantfansam
Copy link
Contributor

I'm with @ahayworth on this one - would prefer not to introduce the complexity associated with supporting super-old versions.

@plantfansam
Copy link
Contributor

See also #103

@github-actions
Copy link
Contributor

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

@github-actions github-actions bot added the stale Marks an issue/PR stale label Apr 27, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Dec 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Marks an issue/PR stale
Projects
None yet
Development

No branches or pull requests

4 participants