Cached read versions should allow staleness bounds to be specified as a transaction option
- Dominant language
- C++
- Stars
- 16.7k
- Forks
- 1.6k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 126
Description
The cached read version feature (see: #5725) in its first round allowed the client to specify a staleness bound on each cached version, and it would refetch a new read version if the cached version was too old. The staleness parameter was specified as a client knob, which meant that it can't be changed without rebooting the process or set to different values for different transactions. I don't know if I have a totally compelling reason for why different transactions might have different staleness bounds, but exposing this as a transaction option would give the user the ability to adjust this threshold more easily than a client knob would.
Contributor guide
Research direction
Start by reading issue #5725 and tracing the cached read version implementation and its existing client knob. Determine how transaction options are defined and used, then verify that staleness can be set per transaction and that cached versions are refetched when the bound is exceeded.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- databases, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100