mirror of
https://github.com/scylladb/scylladb.git
synced 2026-05-28 10:41:12 +00:00
114419d6ab
`set_group0_upgrade_state` writes the on-disk state first, then in-memory state second, both under a write lock. `get_group0_upgrade_state` would only take the lock if the in-memory state was `use_pre_raft_procedures`. If there's an external observer who watches the on-disk state to decide whether Raft upgrade finished yet, the following could happen: 1. The node wrote `use_post_raft_procedures` to disk but didn't update the in-memory state yet, which is still `synchronize`. 2. The external client reads the table and sees that the state is `use_post_raft_procedures`, and deduces that upgrade has finished. 3. The external client immediately tries to perform a schema change. The schema change code calls `get_group0_upgrade_state` which does not take the read lock and returns `synchronize`. The schema change gets denied because schema changes are not allowed in `synchronize`. Make sure that `get_group0_upgrade_state` cannot execute in-between writing to disk and updating the in-memory state by always taking the read lock before reading the in-memory state. As it was before, it will immediately drop the lock if the state is not `use_pre_raft_procedures`. This is useful for upgrade tests, which read the on-disk state to decide whether upgrade has finished and often try to perform a schema change immediately afterwards. Closes #11672