#2635 update image volume in db ASAP
Merged 2 years ago by tkopecek. Opened 2 years ago by tkopecek.
tkopecek/koji issue2634  into  master

file modified
+4 -4
@@ -13830,7 +13830,6 @@ 

          build_info = get_build(build_id, strict=True)


          # check volume policy

-         vol_update = False

          policy_data = {

              'build': build_info,

              'package': build_info['name'],
@@ -13842,7 +13841,10 @@ 

          if vol['id'] != build_info['volume_id']:

              build_info['volume_id'] = vol['id']

              build_info['volume_name'] = vol['name']

-             vol_update = True

+             update = UpdateProcessor('build', clauses=['id=%(build_id)i'],

+                                      values={'build_id': build_id})

+             update.set(volume_id=build_info['volume_id'])

+             update.execute()


          self.importImage(task_id, build_info, results)

@@ -13856,8 +13858,6 @@ 

                                   values={'build_id': build_id})

          update.set(id=build_id, state=st_complete)


-         if vol_update:

-             update.set(volume_id=build_info['volume_id'])


          build_info = get_build(build_id, strict=True)


Metadata Update from @tkopecek:
- Pull-request tagged with: testing-ready

2 years ago

Metadata Update from @jcupova:
- Pull-request tagged with: testing-done

2 years ago

rebased onto 234ced2

2 years ago

Commit 548cb4a fixes this pull-request

Pull-Request has been merged by tkopecek

2 years ago

Side note: this changes introduces a double update to the same row in a single transaction.

While there should be nothing wrong with such a thing, we have avoided this in Koji because of problems with Postgres deadlocks in the past. At least at one point, postgres locking behavior for could be thrown off by double updates like this, leading to deadlocks. However, I'm not sure if that is still the case. I'll file a follow-up ticket to remind us to investigate.