Upload processing may reach a transaction deadlock when closing bugs

Bug #405805 reported by Celso Providelo
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

Logging of the incident:

{{{
2009-07-28 11:45:11 DEBUG Created i386 build of torbutton 1.2.1-1ubuntu2 in ubuntu karmic RELEASE [1137540] in Primary Archive for Ubuntu (1755)
2009-07-28 11:45:11 DEBUG Closing bugs.
/srv/launchpad.net/codelines/soyuz-production-rev-8312/lib/lp/bugs/model/bugtask.py:648: UserWarning: shortlist() should not be used here. It's meant to listify sequences with no more than 15 items. There were 26 items.
  return self.getConjoinedMaster(shortlist(self.bug.bugtasks))
2009-07-28 11:45:14 ERROR Exception while accepting: deadlock detected
DETAIL: Process 18239 waits for ShareLock on transaction 184906003; blocked by process 772.
Process 772 waits for ShareLock on transaction 184905870; blocked by process 18239.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."bug" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
 -> http://launchpadlibrarian.net/29615810/2xhALOBJneX97lQ9BJVkZ1tItvT.txt (deadlock detected
DETAIL: Process 18239 waits for ShareLock on transaction 184906003; blocked by process 772.
Process 772 waits for ShareLock on transaction 184905870; blocked by process 18239.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."bug" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x")
}}}

Revision history for this message
Celso Providelo (cprov) wrote :

The whole transaction was aborted and no email was sent.

We can't really avoid the deadlock (which was probably caused by concurrent changes to the bug) but we certainly could at least send the rejection-message.

In an ideal scenario we may also retry the transaction.

Changed in soyuz:
importance: Undecided → Medium
status: New → Triaged
Changed in launchpad:
importance: Medium → High
Revision history for this message
Robert Collins (lifeless) wrote :

Upload processing has been overhauled since this, and can/should be made into an API (of some sort) client I think, which would eliminate room for such things. conflicts can occur on any row the upload processor is working on; the right thing to do is what the appservers do: retry the whole transaction, not fail the upload.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.