Auto merge of #2192 - jtgeibel:prod/revert-2157, r=jtgeibel

Revert changes to update_downloads task in #2157

It appears that the additional wrapper transaction added around the
update_downloads task causes delays and timeouts to download requests
whenever the background job is run.  Reverting so that master can be
deployed.

r? @ghost

Author: bors

src/tasks.rs

@@ -3,8 +3,3 @@ mod update_downloads;
 
 pub use dump_db::dump_db;
 pub use update_downloads::update_downloads;
-
-use diesel::sql_types::BigInt;
-sql_function!(fn pg_try_advisory_xact_lock(key: BigInt) -> Bool);
-
-const UPDATE_DOWNLOADS_ADVISORY_LOCK_KEY: i64 = 1;

src/tasks/update_downloads.rs

@@ -1,5 +1,3 @@
-use super::pg_try_advisory_xact_lock;
-use super::UPDATE_DOWNLOADS_ADVISORY_LOCK_KEY as LOCK_KEY;
 use crate::{
     background_jobs::Environment,
     models::VersionDownload,
@@ -11,17 +9,9 @@ use swirl::PerformError;
 
 #[swirl::background_job]
 pub fn update_downloads(env: &Environment) -> Result<(), PerformError> {
-    use diesel::select;
-
     let conn = env.connection()?;
-    conn.transaction::<_, PerformError, _>(|| {
-        // If this job runs concurrently with itself, it could result in a overcount
-        if !select(pg_try_advisory_xact_lock(LOCK_KEY)).get_result(&*conn)? {
-            return Err("The advisory lock for update_downloads is already taken".into());
-        }
-
-        update(&conn).map_err(Into::into)
-    })
+    update(&conn)?;
+    Ok(())
 }
 
 fn update(conn: &PgConnection) -> QueryResult<()> {