On Fri, Mar 11, 2022 at 02:41:23PM +0530, Nitin Jadhav wrote: > > Ok. I agree that it is difficult to interpret it correctly. So even if > say that a new checkpoint has been explicitly requested, the user may > not understand that it affects current checkpoint behaviour unless the > user knows the internals of the checkpoint. How about naming the field > to 'throttled' (Yes/ No) since our objective is to show that the > current checkpoint is throttled or not.
-1 That "throttled" flag should be the same as having or not a "force" in the flags. We should be consistent and report information the same way, so either a lot of flags (is_throttled, is_force...) or as now a single field containing the set flags, so the current approach seems better. Also, it wouldn't be much better to show the checkpoint as not having the force flags and still not being throttled. Why not just reporting (ckpt_flags & (CHECKPOINT_REQUESTED | CHECKPOINT_IMMEDIATE)) in the path(s) that can update the new flags for the view? CHECKPOINT_REQUESTED will always be set by RequestCheckpoint(), and can be used to detect that someone wants a new checkpoint afterwards, whatever it's and whether or not the current checkpoint to be finished quickly. For this flag I think it's better to not report it in the view flags but with a new field, as discussed before, as it's really what it means. CHECKPOINT_IMMEDIATE is the only new flag that can be used in an already in progress checkpoint, so it can be simply added to the view flags.
