Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kv: support server-side refreshes of uncertainty errors #75905

Commits on Feb 8, 2022

  1. kv: support server-side refreshes of uncertainty errors

    Extracted from cockroachdb#73732, with relevant comments addressed.
    
    This commit adds support for server-side refreshes of
    `ReadWithinUncertaintyIntervalError`s. This serves as a performance optimization
    for transactional requests, which now benefit from this new capability to
    refresh away `ReadWithinUncertaintyIntervalErrors` early in their transaction,
    before they've accumulated any refresh spans. There's some complexity around
    supporting this form of server-side retry, because it must be done above
    latching, instead of below. However, the recent refactoring in cockroachdb#73557 has made
    this possible to support cleanly.
    
    Specifically, we now handle `ReadWithinUncertaintyIntervalError` as a concurrency
    error in the `executeWithConcurrencyRetries` retry loop. This is different from
    other server-side retries, which are hit during writes and can be handled without
    releasing latches. This difference stems from the difference in how read and write
    latches behave. Write latches protect their MVCC timestamp and any later time.
    Meanwhile, read latches protect their MVCC timestamp and any earlier time. This
    means that a request holding read latches that hits an uncertainty error can't
    refresh without dropping those latches and acquiring new ones.
    
    This is also a prerequisite to giving non-transactional requests uncertainty
    intervals (cockroachdb#73732), because we don't want ReadWithinUncertaintyIntervalErrors to
    reach the client for non-transactional requests. Conveniently, because
    non-transactional requests are always scoped to a single-range, those that hit
    uncertainty errors will always be able to retry on the server, so these errors
    will never bubble up to the client that initiated the request.
    
    Release note (performance improvement): Certain forms of automatically retried
    "read uncertainty" errors are now retried more efficiently, avoiding a network
    round trip.
    nvanbenschoten committed Feb 8, 2022
    Configuration menu
    Copy the full SHA
    a095546 View commit details
    Browse the repository at this point in the history