[SERVER-41931] Remove forceRollbackViaRefetch flag Created: 26/Jun/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 4.0.10, 4.2.0-rc2 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
If the forceRollbackViaRefetch parameter is set to true, we will hit an invariant when trying to do a rollback. The intended behavior is for us to use the rollbackViaRefetch algorithm no matter what, even if the storage engine supports the recover-to-timestamp functionality. |
| Comments |
| Comment by Alyson Cabral (Inactive) [ 26/Jun/19 ] |
|
Ok, yeah, let's get rid of it. |
| Comment by Judah Schvimer [ 26/Jun/19 ] |
|
We introduced it because we were afraid that recover to a timestamp could have a bad bug and we wanted an easy way for users to fall back on the old algorithm if they were having a problem with the new rollback algorithm. Apparently they never actually could due to this invariant. |
| Comment by Alyson Cabral (Inactive) [ 26/Jun/19 ] |
|
Why did we introduce the flag? Why would users have used it in the past? |
| Comment by Judah Schvimer [ 26/Jun/19 ] |
|
I think on 4.2, we do not want to try to support this parameter. We have no testing of how it will interact with prepare (it will likely invariant). On 4.0 it was supposed to work and I don't see why it shouldn't work minus the invariant we're hitting. alyson.cabral, do we care about this flag, or should we just remove it since we barely test it, and clearly no one is using it? |
| Comment by William Schultz (Inactive) [ 26/Jun/19 ] |
|
This is a bug on both 4.0 and 4.2. At first glance it appears we have at least one test on 4.2 that utilizes the forceRollbackViaRefetch parameter, but in that test the rollback actually fails hereĀ before we ever hit the problematicĀ invariant. On 4.0, a grep for "forceRollbackViaRefetch" turns up matches only in bgsync.cpp, bgsync.h, and rs_rollback.h, so we don't have any test coverage of the parameter there. |