-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
ActiveRecord 7.1 with ActiveSupport::Concurrency::NullLock doesn't keep the connection in the thread, PostgreSQLAdapter repeatedly calling load_types_queries #49976
Comments
Can you paste the full backtrace here? And it would be helpful if you can create a sample reproduction app. |
The full backtrace looks like this:
I'll try to find time to set up a full reproduction app but I'm pretty swamped at the moment unfortunately. Important to note that this is resolved by changing this line in the initializer:
to
|
After further digging through the source code, I've found this can be solved in rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb Line 176 in 60d05cd
setting:
Seems the defaults may have changed here? |
I believe Apartment does unsupported things with the Active Record API; it doesn't seem surprising that that would break in response to changing internals between AR versions. We'd need a reproduction using only published APIs to explore this further. |
We use multitenancy through a legacy gem that we haven't been able to get rid of yet (Apartment), and after upgrading from Rails 7.0 to 7.1 we noticed massively increased database load coming from a huge amount of slow calls looking like:
This seems to come from
PostgreSQLAdapter#load_types_queries
, and to debug this I added:Just so that it would print out the whole trace of where it was coming from and how it was getting there. It seems like every time the connection is being accessed, calling
active?
then callsverify!
, and for some reason,@raw_connection
is always nil now.Comparing the source from 7.0 to 7.1, it seems to be related to how
ActiveRecord::ConnectionAdapters::AbstractAdapter
has changed to useActiveSupport::Concurrency::NullLock
, rather thanActiveSupport::Concurrency::LoadInterlockAwareMonitor
. Forcibly changing this lock back seems to resolve the issue here, andPostgreSQL#reload_type_map
is no longer being called, but this locking isn't configurable anywhere, and will always be set to useNullLock
.Steps to reproduce
Easiest way to get an overview of these queries being run I found was to add an exception, catch it and print the backtrace:
Expected behavior
If the connection is being reset while still executing inside the same thread, then at least cache the results from the types queries to avoid firing this query again and again. On databases with large amounts of tables and/or schemas, this can be a very expensive query
Actual behavior
Connection is being
reset!
and reconfigured repeatedly in the same thread, we're seeing this call 3-5 times per request on top of when switching schemasSystem configuration
Rails version: 7.1.1
Ruby version: 3.2.2
The text was updated successfully, but these errors were encountered: