-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Misleading log messages about opening connections #2511
Comments
@jtalmi You asked if we had any more good first issues - I think this is a great one! I know that was a month ago, but let me know if you're interested in picking this up. |
I'd like to take this issue if it hasn't been assigned yet. |
@southpolemonkey go for it! Let us know if there's anything we can do to help out :) |
@drewbanin awesome! which branch should I base off? |
you're going to want |
(#2511) Remove log messages about opening connections in set_connecti…
Describe the bug
When dbt is parsing, it assigns a "connection name" for each model it's parsing, just in case it's needed. This goes through
set_connection_name
, which logs that it isAcquiring new postgres connection ...
andOpening a new connection, ...
. This behavior was very reasonable before dbt lazy-loaded connections, because it's the last centralized place before we end up in the adapter-specificopen
classmethod, so it's a nice place to send that message.Since dbt doesn't generally need to access adapter connections during parsing, this log message is extremely misleading, and leads users who inspect the debug logs to believe that what's taking a long time is opening a ton of connections. What's actually (probably) taking a long time is parsing jinja. It would be good to know either way!
We should move the message about
Opening a new connection
into the part ofLazyHandle
that callsopen
.I would like
Acquiring
to stay (though I'm very open to rewording it) as it's a very useful message in the event of weird threading-related connection issues. We haven't had any of those in a while, but I assume that as soon as we remove the message we'll introduce a slew of connection management problems somehow...Steps To Reproduce
select 1 as id
dbt ls
Expected behavior
At the end of the day, I don't expect dbt to log that it's "Opening" a connection unless we're opening a socket (or at least trying to).
Screenshots and log output
System information
Any database, any supported python version, any OS,
dbt >= 0.15.1
The text was updated successfully, but these errors were encountered: