{"push_id":2818069772,"size":2,"distinct_size":0,"ref":"refs/heads/master","head":"86090211604c9b8f7ab24a5abaf1cb6e4e27a41f","before":"a9ce8f69ab66f2bb00f9dcfa4041d060b8410556","commits":[{"sha":"7c70077223535ec34afdead74d39a0c43fe04f78","author":{"name":"Nikhil Benesch","email":"0e70f566aa977bafe6ad237291a2aeff1c9dbb46@gmail.com"},"message":"storage: check for in-progress merge before installing new lease\n\nDuring a merge, it is possible for the RHS lease to change hands, e.g.,\nwhen the original leaseholder dies and another member of the range\nacquires the lease. In this case, the new leaseholder is responsible for\nchecking for a deletion intent on its local range descriptor; if it\ndiscovers such an intent, a merge is in progress and the leaseholder is\nrequired to block all traffic unless it can prove that the merge\naborted.\n\nThe previous implementation of this scheme had a small window in which\nthe new leaseholder had installed a valid lease but had not yet\ninstalled a mergeComplete channel to block all traffic. This race was\nnever seen in practice, but it could, in theory, lead to a\nserializability violation.\n\nReorder the flow post-lease acquisition so that checking for an\nin-progress merge occurs before the new lease is installed.\n\nRelease note: None","distinct":false,"url":"https://api.github.com/repos/cockroachdb/cockroach/commits/7c70077223535ec34afdead74d39a0c43fe04f78"},{"sha":"86090211604c9b8f7ab24a5abaf1cb6e4e27a41f","author":{"name":"craig[bot]","email":"3a2c29237f73c7cf88424b80e427b1884f346b35@cockroachlabs.com"},"message":"Merge #28894\n\n28894: storage: check for in-progress merge before installing new lease r=nvanbenschoten a=benesch\n\nDuring a merge, it is possible for the RHS lease to change hands, e.g.,\r\nwhen the original leaseholder dies and another member of the range\r\nacquires the lease. In this case, the new leaseholder is responsible for\r\nchecking for a deletion intent on its local range descriptor; if it\r\ndiscovers such an intent, a merge is in progress and the leaseholder is\r\nrequired to block all traffic unless it can prove that the merge\r\naborted.\r\n\r\nThe previous implementation of this scheme had a small window in which\r\nthe new leaseholder had installed a valid lease but had not yet\r\ninstalled a mergeComplete channel to block all traffic. This race was\r\nnever seen in practice, but it could, in theory, lead to a\r\nserializability violation.\r\n\r\nReorder the flow post-lease acquisition so that checking for an\r\nin-progress merge occurs before the new lease is installed.\r\n\r\nRelease note: None\r\n\r\n---\r\n\r\n@tschottdorf this is exceptionally hard to write a test for. `TestStoreRangeMergeRHSLeaseExpiration` tests exactly this scenario and yet never hit this race condition. Thoughts?\n\nCo-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>","distinct":false,"url":"https://api.github.com/repos/cockroachdb/cockroach/commits/86090211604c9b8f7ab24a5abaf1cb6e4e27a41f"}]}
{"actor":{"display_login":"craig"}}