fn forced_cutover_pending(state: &ClusterState, now: Timestamp) -> boolExpand description
Whether a forced cut-over is imminent: an in-progress reconfiguration is
past its deadline under ON TIMEOUT COMMIT, so the next cut-over commits
the target whether or not it hydrated.
In that window the baseline yields its realized-shape replicas. Overlapping the two sets only buys availability while the target hydrates, and a forced cut-over has given up on hydration. Yielding turns the reshape into one transaction that retires the realized replicas and creates the target’s, so it has to fit the larger of the two shapes rather than their sum. That is what lets a resize succeed on a budget that has no room for overlap, and it is the only way to shrink a cluster that is already near its limit.
If that single transaction still does not fit, it is rejected whole and the
record is left in progress for ClusterController::shed_decision to shed,
so an unaffordable target stays observable rather than half-applied.