> Yeah, I understand each of these tradeoffs in isolation. What concerns me is > their > cumulative effect: we moved from wanting to reject mismatched states to > warning > about them, and we are now considering leaving some known rollback cases > unhandled > to keep the patch manageable. > > Also, I’m not sure 1 and 3 are limited to engineered situations. Even without > immediate crashes, they can leave the nodes with mismatched states, which is > what the patchset is trying to address.
1, for example requires executing an offline change quickly after an online change. I'm not saying that it shouldn't work better, just questioning how realistic that scenario is. > Yeah, but if the resulting patch ends up being significantly more complex, > that > would not be reassuring either. and > > I'll try to look into what adding the two > > patches together looks like, but it most likely combines their size, > > as they improve the current master code in different ways. > > Thanks! I looked into this, and I was right that if I add the pg_control changes to v4 it nearly doubles the size of the actual code changes from ~300 to ~550 lines, and fixes all the issues you reported while also keeping the existing suite of tests passing. The diff compared to v4 is relatively simple, so I don't think that would be an issue by itself, but it's another control version change.
