ArchiveView.num_pkgs_building is not ready for copy archives

Bug #429318 reported by Michael Nelson
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Michael Nelson

Bug Description

IArchiveView.num_pkgs_building was written not written with copy archives in mind and uses IBuildSet.getBuildsForArchive() to get all building builds, and separately all pending builds. It then iterates through these to get sets of the related SPR's (and do a simple set-operation). When copy archives have huge numbers of pending builds, this times out while calculating one of the prejoins specified for getBuildsForArchive.

Specifically, the results are being left-joined on a number of tables that are not relevant for this particular calculation (but are used by other call-sites), including LibraryFileAlias and Builder, resulting in a timeout at:

LEFT JOIN Builder ON Builder.id = Build.builder WHERE Build.id IN (%s, %s, %s, %s, %s, %s, %s, %s, %s,... (x1000s for a copy archive that's just been initialized).

I'd suggest we don't try to re-use getBuildsForArchive and instead create a simple query (without pre-joins) that simply groups by SPR. Then we can count the grouped results (after the doing a difference operation for the needs build - (see in num_pkgs_building).

See: OOPS-1350EA464

Tags: lp-soyuz
Changed in soyuz:
assignee: nobody → Julian Edwards (julian-edwards)
Changed in soyuz:
assignee: Julian Edwards (julian-edwards) → Michael Nelson (michael.nelson)
Changed in soyuz:
status: Triaged → In Progress
Revision history for this message
Diogo Matsubara (matsubara) wrote : Bug fixed by a commit
Changed in soyuz:
status: In Progress → Fix Committed
Changed in soyuz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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