-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
138706: slstorage: do not use InitPut with FailOnTombstones on Insert r=yuzefovich a=yuzefovich This commit switches the usage of `InitPut` KV request when inserting a new sql liveness session from `FailOnTombstones=true` to `FailOnTombstones=false`. The contract of the `Insert` method is that the caller should never provide previously used session ID which is achieved by generating a random V4 UUID, so the probability of ever generating a duplicate is miniscule. The usage of `FailOnTombstones=true` option provides additional protection if the same session ID is reused within the GC TTL of the relevant range (because tombstones would get removed on MVCC garbage collection and/or compactions in pebble). This usage was introduced in 686f323 where we switched from SQL INSERT statement - which behaved similar to `FailOnTombstones=false`. My main motivation behind this change is that this is the only place where we use `FailOnTombstones=true` option of the InitPut, and we're about to deprecate the InitPuts in favor of CPuts, yet CPuts don't have this option which would make the deprecation process more involved. Also I think the current handling of this scenario by the code is partially broken. Namely, if previously used session ID is provided while there is a tombstone on the relevant key, the ConditionFailedError would be returned, and the loop in `Instance.createSession` would exceed the retry duration because on this error type we do not reset `session.id` field. This will result in not being able to create a session by the SQL instance, so it will fatal the process. On a quick search via Glean we never encountered this fatal before though. With the change in this commit in the case of inserting the previously used session ID the behavior is undefined (I think one possible scenario is that other SQL instances won't be able to see this new instance because they have cached the session ID in the deadSessions cache, so the new instance won't be used for distributed queries; there are probably other consequences too). Still, it seems reasonable to me to rely on randomly-generated UUIDs never repeating without additional - but only temporary - protection of `FailOnTombstones`. Informs: #71074. Epic: None Release note: None 138748: sql: minor refactor of partial stats r=mgartner a=mgartner Epic: None Release note: None Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: Marcus Gartner <[email protected]>
- Loading branch information
Showing
3 changed files
with
23 additions
and
18 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters