DETAIL: Process 24328 waits for ShareLock on transaction 16779530; blocked by process 5888.
Process 5888 waits for ShareLock on transaction 16779529; blocked by process 24328.
HINT: See server log for query details.
CONTEXT: while locking tuple (2738,13) in relation "XXXXXXXXX"
SQL statement "SELECT 1 FROM ONLY "public"."XXXXXXXXX" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x"
I'm not sure whether the problem is caused by this gem.
I post anyway just in case anyone else encountered a deadlock issue.
I cannot imagine how a deadlock could occur while updating a single record.
Could callbacks that involve other tables create the problem?
I don't understand how Rail's locking happens under the hood.
That lack of deep understanding could be causing me to do something that causes the problem.
I am not explicitly using locks.
Backtrace
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/postgresql_adapter.rb:672:in `exec_params'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/postgresql_adapter.rb:672:in `block (2 levels) in exec_no_cache'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/dependencies/interlock.rb:48:in `block in permit_concurrent_loads'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/concurrency/share_lock.rb:187:in `yield_shares'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/dependencies/interlock.rb:47:in `permit_concurrent_loads'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/postgresql_adapter.rb:671:in `block in exec_no_cache'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/abstract_adapter.rb:696:in `block (2 levels) in log'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/concurrency/load_interlock_aware_monitor.rb:26:in `block (2 levels) in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/abstract_adapter.rb:695:in `block in log'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/abstract_adapter.rb:687:in `log'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/postgresql_adapter.rb:670:in `exec_no_cache'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/postgresql_adapter.rb:649:in `execute_and_clear'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/connection_adapters/postgresql/database_statements.rb:53:in `exec_query'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/connection_adapters/postgresql/database_statements.rb:12:in `exec_upsert'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/connection_adapters/postgresql/database_statements.rb:8:in `upsert'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/compatibility/rails60.rb:12:in `upsert'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/persistence.rb:83:in `_upsert_record'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/timestamp.rb#4:in `_upsert_record'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/persistence.rb:14:in `block (2 levels) in upsert!'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/callbacks.rb:106:in `run_callbacks'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/persistence.rb:9:in `block in upsert!'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/callbacks.rb:117:in `block in run_callbacks'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.6/lib/active_record/autosave_association.rb:385:in `around_save_collection_association'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/callbacks.rb:126:in `block in run_callbacks'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.6/lib/active_support/callbacks.rb:137:in `run_callbacks'
/app/vendor/bundle/ruby/2.7.0/gems/active_record_upsert-0.11.1/lib/active_record_upsert/active_record/persistence.rb:8:in `upsert!'
I'm not sure whether the problem is caused by this gem. I post anyway just in case anyone else encountered a deadlock issue. I cannot imagine how a deadlock could occur while updating a single record. Could callbacks that involve other tables create the problem? I don't understand how Rail's locking happens under the hood. That lack of deep understanding could be causing me to do something that causes the problem. I am not explicitly using locks.
Backtrace