)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"c073e5ffea879ef26fbca9a4ea49a0cd471781f7","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Use a lock to deal with the following scenarios:"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"1. The _misplaced_objects handler in process A is removing misplaced"},{"line_number":12,"context_line":"object rows from db while an rsync_then_merge in process B"},{"line_number":13,"context_line":"concurrently attempts to relink the db file, potentially causing"},{"line_number":14,"context_line":"misplaced row ranges to be removed from a different db from which they"},{"line_number":15,"context_line":"were moved."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Now, _misplaced_objects will contend for a lock with rsync_then_merge,"},{"line_number":18,"context_line":"and once lock is acquired will confirm the db id is that from which"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"9f6a8fd7_b9024d3c","line":15,"range":{"start_line":11,"start_character":0,"end_line":15,"end_character":11},"updated":"2018-04-20 16:39:13.000000000","message":"This is no longer expected since we no longer replicate objects between sharding dbs - https://review.openstack.org/549678","commit_id":"146dddaaef2109f4743e7f7c77d58f0da168b526"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"c073e5ffea879ef26fbca9a4ea49a0cd471781f7","unresolved":false,"context_lines":[{"line_number":18,"context_line":"and once lock is acquired will confirm the db id is that from which"},{"line_number":19,"context_line":"rows were moved."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"2. An rsync_then_merge in process A re-links retiring db concurrently"},{"line_number":22,"context_line":"with a _complete_sharding in process B unlinking the retiring db"},{"line_number":23,"context_line":"(requires the rsync_then_merge to have been in progress since before"},{"line_number":24,"context_line":"sharding began)."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Now, rsync_then_merge will contend for lock with _complete_sharding"},{"line_number":27,"context_line":"and check the old db file still exists before renaming its new db"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"9f6a8fd7_bc3d5b2c","line":24,"range":{"start_line":21,"start_character":0,"end_line":24,"end_character":16},"updated":"2018-04-20 16:39:13.000000000","message":"looking again at this scenario, there\u0027s actually a couple of possibilities:\n\n1.  rsync starts before sharding, then rsync_then_merge is received in process A and starts merging *retiring* db rows to rsync\u0027d file, then sharding starts in process B, then process A renames rsync file to retiring db file concurrently with process B unlinking the retiring db file - rows might be lost!\n\n2. rsync starts before sharding, then sharding starts in process B, then rsync_then_merge is received in process A and merges *fresh* db rows to rsync\u0027d file, then renames rsync file to fresh db file - no rows lost but fresh db polluted!","commit_id":"146dddaaef2109f4743e7f7c77d58f0da168b526"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"c073e5ffea879ef26fbca9a4ea49a0cd471781f7","unresolved":false,"context_lines":[{"line_number":27,"context_line":"and check the old db file still exists before renaming its new db"},{"line_number":28,"context_line":"file."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"3. usync merge in process A writes rows to retiring db concurrently"},{"line_number":31,"context_line":"with a _complete_sharding in process B unlinking the retiring db"},{"line_number":32,"context_line":"(requires the usync to have been in progress since before sharding"},{"line_number":33,"context_line":"began)."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Now, usync will contend for lock with _complete_sharding and check the"},{"line_number":36,"context_line":"old db file still exists before returning success."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"9f6a8fd7_d96aa1eb","line":33,"range":{"start_line":30,"start_character":0,"end_line":33,"end_character":7},"updated":"2018-04-20 16:39:13.000000000","message":"This is unlikely because _complete_sharding checks that max row has not changed since the start of cleaving, so the usync would need to have started before the db began sharding *and* written no rows since the db started cleaving.","commit_id":"146dddaaef2109f4743e7f7c77d58f0da168b526"}]}