Description of problem: The problem of deadlock still occurs when doing bulk syncing. Version-Release number of selected component (if applicable): 6.11.3 snap 2 How reproducible: 100% Steps to reproduce: Note: Ensure Capsule is setup to have 8 pulpcore workers 1) Enable and sync a large Red Hat repository. I use "Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server x86_64 7Server" in my reproducer. 2) Set the Capsule download policy to "immediate". 3) Create a new lifecycle environment named 'devel'. Add only it to the Capsule. Remove all other lifecycle environments from the Capsule. 4) In Settings page, Content tab, set "Sync Capsules after Content View promotion" to "No" 5) Create 1 content view and attach repo in step (1) to it. 6) Make 7 copies of the content view. 7) Publish and promote all 8 content views to 'devel' environment. 8) Trigger a complete capsule sync. Expected results: No deadlocks Actual results: From /var/lib/pgsql/data/log/postgresql-Wed.log : 2022-09-14 13:33:41 EDT ERROR: deadlock detected 2022-09-14 13:33:41 EDT DETAIL: Process 5823 waits for ShareLock on transaction 250066; blocked by process 5764. Process 5764 waits for ShareLock on transaction 254024; blocked by process 5823. Process 5823: COMMIT Process 5764: SELECT "core_contentartifact"."pulp_id", "core_contentartifact"."pulp_created", "core_contentartifact"."pulp_last_updated", "core_contentartifact"."artifact_id", "core_contentartifact"."content_id", "core_contentartifact"."relative_path" FROM "core_contentartifact" WHERE "core_contentartifact"."pulp_id" IN (SELECT U0."pulp_id" FROM "core_contentartifact" U0 WHERE U0."pulp_id" IN ('6749120e-f1e3-4404-9e29-296f164dd242'::uuid, 'fb0ca697-d4d2-493a-b3c9-6fd60de82770'::uuid, '7a11c2b5-068d-4432-8b68-4a762f767537'::uuid, '3cdd449b-c3ca-41fa-93ab-b9fc93f95197'::uuid, 'ce22e8b9-7984-4a59-867c-43fe4450378e'::uuid, '70927e70-fe17-4ace-a2a4-534436deac58'::uuid, '18d99f1f-5b7d-45f2-af45-b178750d81d6'::uuid, '3bc75153-2461-4766-b8e7-29a71c3e716f'::uuid, 'bb8cc0c9-9384-44f0-b05d-a4341ea73fd8'::uuid, 'df1066f2-30d8-4798-8f12-2fb42f14658d'::uuid, '9d667dab-10c9-4db0-8452-9b5ba80463e7'::uuid, 'd39ce5e5-c2c3-43f5-a0f5-34b2cd9377af'::uuid, 'f1fb0c92-88d1-41f4-b129-87d9613d4e96'::uuid, '1db036b4-1cb7-4e48-91d4-00cfb6471c23'::uu 2022-09-14 13:33:41 EDT HINT: See server log for query details. 2022-09-14 13:33:41 EDT CONTEXT: while locking tuple (225,46) in relation "core_contentartifact" SQL statement "SELECT 1 FROM ONLY "public"."core_contentartifact" x WHERE "pulp_id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x" 2022-09-14 13:33:41 EDT STATEMENT: COMMIT 2022-09-14 13:33:41 EDT LOG: duration: 1466.274 ms statement: SELECT "core_contentartifact"."pulp_id", "core_contentartifact"."pulp_created", "core_contentartifact"."pulp_last_updated", "core_contentartifact"."artifact_id", "core_contentartifact Additional info:
I did observe that if I did a complete resync, then it sync successfully.
Further investigation shows that this is the "other side" of the problem we're already working on under BZ#2082209 (for 6.11) and BZ#2062526 (for 6.12). Since this is reported against 6.11, I am closing as a dup of '2209 *** This bug has been marked as a duplicate of bug 2082209 ***