Comment 2 for bug 325445

The queries are all fast.

The OOPS reports state a massive amount of non-SQL time.

Looking at how the timeouts are currently implemented, we have no way of knowing if this was genuinely non-SQL time, or time spent waiting for a lock and attempting that last SQL query.

I think canonical.launchpad.webapp.adapter.LaunchpadTimeoutTracer needs to be fixed, checking if get_remaining_time() is positive before even attempting to issue a query - this will tell us if time has been spent in Python for some reason rather than time spend waiting on the db.

Nothing should be blocking that query - the only operations that block a select we only do during rollouts.